Designing a Billion‑Scale Open Platform: Architecture & Performance

Chapter 1: Overall Architecture – From Three‑Layer Decoupling to Traffic Partitioning

Open platforms must endure massive traffic and concurrency; a mature platform requires stability, scalability, security, and ecosystem support. The architecture is divided into three layers: Access Layer (gateway routing, authentication, traffic control – Nginx, API Gateway, OAuth2), Capability Layer (business capability orchestration, microservice decoupling – Spring Cloud, Dubbo, Kafka), and Infrastructure Layer (data storage, cache, messaging, monitoring – MySQL, Redis, RocketMQ, Prometheus).

Key goals include handling high traffic, flexible capability composition, ecosystem compatibility, and observability & recovery.

Access Layer focuses on external request handling and security.

Capability Layer encapsulates business logic and service orchestration.

Infrastructure Layer provides storage and foundational services.

Access Layer: API Traffic First Defense

Implements rate limiting (token bucket), signature verification (HMAC‑SHA256), unified authentication (OAuth2.0), and gray‑release to control rollout.

Capability Layer: Microservice‑Based Capability Orchestration

Uses service governance (circuit breaking, rate limiting, retries via Hystrix or Sentinel), configuration and registration centers (Nacos, Apollo), and flexible capability composition to combine multiple microservices per request.

Infrastructure Layer: Supporting Billion‑Level Throughput

Employs sharding, read/write separation, distributed cache (Redis cluster), message queues (Kafka, RocketMQ), and observability tools (SkyWalking, Prometheus) to ensure performance and fault detection.

Chapter 2: Cache System Design and Hotspot Isolation

Cache aims to absorb massive read traffic and reduce latency without replacing the database. A three‑level cache hierarchy is recommended:

L1: Local in‑process cache (e.g., Caffeine) for nanosecond access.

L2: Distributed cache (Redis cluster) shared across instances.

L3: CDN edge cache for static content.

The multi‑level cache funnel, combined with Bloom filters, protects the backend database during peak traffic such as Double‑11, handling tens of millions of QPS.

Chapter 3: Asynchronous Architecture – Message Queues as Traffic Buffers

Asynchronous processing decouples modules, smooths traffic spikes, and provides retry and dead‑letter mechanisms. Example diagram shows order processing split into async steps, with Kafka buffering overload.

Chapter 4: Database Elastic Design – Sharding and High‑Performance Governance

Horizontal sharding enables capacity expansion; read/write separation improves query throughput; global unique IDs avoid key collisions; hotspot table strategies (caching, partitioning, async batch writes) prevent bottlenecks.

Chapter 5: Distributed Transaction Handling – Consistency and Performance

Discusses TCC, Saga, AT, and Seata frameworks for distributed transactions, emphasizing careful use due to complexity and performance cost.

Chapter 6: High‑Availability Architecture – Elastic Scaling

Containerized deployment on Kubernetes enables automatic scaling; multi‑region active‑active deployment ensures fault tolerance and low latency; chaos engineering validates resilience.

Chapter 7: Implementation Roadmap – Gradual Path to Billion‑Scale Traffic

Three phases: 1) Build core APIs and basic high availability; 2) Introduce caching, async processing, microservices, and medium‑scale traffic governance; 3) Expand ecosystem, pursue extreme performance optimization, and implement sophisticated operations.

Author: Zhang Shoufa, Java engineer at Xiankehui.