Shopee Architecture: Scaling for Flash Sales

Chapter 5: Observability - Finding Bugs in the Microservices Jungle Debugging a 30-hop microservice failure requires three pillars of observability: Distributed Tracing via OpenTelemetry, columnar log storage via ClickHouse, and real-time stream processing via Apache Flink. Together, they isolate latency bottlenecks across tens of thousands of pods in seconds. ← Series hub | ← Prev Imagine you are an on-call engineer during the 11.11 mega-sale. Suddenly, alerts go off: Checkout success rates are plummeting, and users are facing continuous Timeouts. In an old Monolithic system, you would simply open error.log and find the exact broken line in the pay() function. However, at Shopee, the lifecycle of a single “Checkout” button press jumps across 30 different services: API Gateway -> Order Service -> Promo Service -> Inventory Service -> Payment Service -> Banking Gateway... ...

Chapter 4: Database Scale - The Rise of TiDB and NewSQL To scale beyond MySQL sharding limitations, Shopee migrated to TiDB—a NewSQL database that provides infinite horizontal scalability by decoupling compute from storage, eliminating the need for manual sharding and distributed transaction logic. ← Series hub | ← Prev | Next → No matter how many layers of Cache or Message Queues you have, the final destination of all transactional data is the Database (the Source of Truth). With tens of millions of daily orders and billions of records, traditional RDBMS like standalone MySQL quickly hit dangerous bottlenecks. The B+Tree index grows too deep, and Disk IOPS reach their physical ceiling. ...

Chapter 3: Peak Shaving - The Power of Apache Kafka and Graceful Degradation To survive 11.11 traffic spikes without database collapse, Shopee shifts heavy processing to asynchronous Kafka queues. The system guarantees checkout survival by enforcing graceful degradation and circuit breakers that disable non-essential features under extreme load. ← Series hub | ← Prev | Next → In Chapter 2, we utilized Redis to deduct inventory in a fraction of a millisecond. However, the purchase journey isn’t over. The system still needs to: Create the order record in MySQL, generate an invoice, deduct money from ShopeePay, calculate shipping, and award Shopee Coins. ...

Chapter 2: Flash Sale Engine - The Mystery Behind Redis and Hot Keys Flash sales generate massive traffic spikes that instantly crush traditional databases via row locks. Shopee solves this using a two-tier caching architecture, atomic Lua scripts in Redis, and inventory sharding to guarantee sub-millisecond response times without overselling. ← Series hub | ← Prev | Next → Flash Sale events are the ultimate stress test for system architecture. When an iPhone is sold for $1, millions of users will smash the “Buy Now” button in the exact same millisecond. If this massive spike hits a MySQL database directly, the system will instantly crash due to Row Locks and Deadlocks. ...

Chapter 1: Building a Massive Foundation with Microservices, Golang, and gRPC Shopee handles millions of concurrent users by abandoning monolithic architectures in favor of microservices built on Golang and gRPC. This foundation guarantees isolated scaling and sub-millisecond inter-service communication. ← Series hub | Next → In the first part of our Shopee architecture series, we dive deep into their foundational layer. To serve millions of concurrent users (high-concurrency), a Monolithic architecture is impossible. A single bottleneck would bring down the entire system. The mandatory solution is the Microservices Architecture. ...