Designing a Billion-User Social Platform: Architecture, Scaling, and Reliability Strategies

1. Community System Architecture

Using DDD domain modeling, the monolithic application is split into multiple Spring Cloud microservices. Each service should stay around 10,000 lines of code to keep it manageable. The system undergoes several rounds of splitting: first separating modules (e.g., order, product, procurement, warehouse, user), then further dividing each sub‑system as complexity grows.

Static assets are served via CDN and Nginx caching, while dynamic pages are rendered with Thymeleaf and cached in Redis. Typical product data size is 10 KB per item; 100 items ≈ 1 MB, 100 k items ≈ 1 GB. During peak traffic the system handles about 3,500 requests per second.

2. CDN, Nginx Static Cache, JVM Cache

Thymeleaf renders pages, Nginx returns static content directly, and dynamic data is fetched from Redis. A dedicated cache service updates Redis when underlying data changes.

3. Cache Layer

Redis Cluster with 10 nodes (5 master, 5 slave) can sustain up to 50 k QPS per master, totaling around 250 k read/write operations per second. Each Redis process is allocated 10 GB memory; exceeding this limit may cause stability issues. High availability is achieved through master‑slave replication with automatic failover.

4. Message Queue (MQ)

MQ decouples microservices and enables asynchronous calls, essential for handling flash‑sale spikes. Kafka can achieve 100 k+ QPS with millisecond latency. Consumers must guarantee successful consumption; otherwise, manual fallback is required. Idempotency is a must.

5. Database Sharding and Read/Write Splitting

To meet high‑concurrency demands, the database is split into multiple instances and tables, keeping each table small for better SQL performance. Read‑heavy workloads use a master‑slave architecture: writes go to the master, reads are served by replicas, with additional slaves added as needed.

6. Elasticsearch

Elasticsearch provides distributed search and aggregation capabilities, supporting both statistical queries and full‑text search for modules such as address books and order queries.

7. Accounting System – Distributed Transaction Consistency

The preferred approach is to avoid distributed transactions: use local DB transactions for single‑process operations and MQ for cross‑process consistency. When strong consistency is required (e.g., financial payments), two practical patterns are used:

Final consistency via reliable MQ delivery.

Maximum‑effort notification with retries and acknowledgments.

More heavyweight solutions such as 2PC, 3PC, TCC, or SAGA are generally too costly for typical internet services.

8. User System – Multithreaded Data Migration

During a data migration project, duplicate processing occurred because multiple threads accessed a shared ArrayList. Replacing it with CopyOnWriteArrayList and ensuring each thread receives an immutable copy of the ID list eliminated the duplication. Proper synchronization of list clearing after each thread finishes is essential.

if (arrayBuffer.length == 99) {
    val asList = arrayBuffer.toList
    exec.execute(openIdInsertMethod(asList))
    arrayBuffer.clear
}

9. Counting System – Massive Counters

For low‑to‑mid scale (tens of thousands), a cache‑plus‑DB approach works: increment the DB, then update Redis or Memcached. For high‑scale (millions of updates per second), store counters directly in Redis using hash sharding, replicate with master‑slave, and employ read/write splitting.

Memory efficiency is a concern: a 4‑byte counter stored as a long key/value pair consumes ~65 bytes in Redis, far above the theoretical 12 bytes. Large‑scale deployments may require terabytes of memory, making pure in‑memory storage costly.

Custom compact data structures to improve storage density.

Cold keys offloaded to SSD with an LRU index in memory.

Asynchronous multi‑threaded replication for cold data.

10. System Design – Microsoft Example

Requirement Collection : Identify target audience (high‑concurrency B2C, high‑availability B2B), service scenarios (instant messaging, gaming, e‑commerce flash sales), and user scale (10k‑level, million‑level, billion‑level).

Top‑Level Design includes core functions (write: post tweet; read: news feed; interaction: like/follow), performance metrics, scalability, latency, availability, and consistency considerations.

Storage Choices :

Key‑value: Redis for hot data.

Document: MongoDB for post content.

Search: Elasticsearch.

Column: HBase/BigTable for big data.

Graph: Neo4j for social graph.

Media: FastDFS for images/videos.

11. Designing a Microblog Platform

Core features: post tweet, timeline, news feed, follow/unfollow, registration/login.

QPS planning:

QPS = 100 → a single laptop can serve.

QPS = 1 K → a decent web server with HA.

QPS = 1 M → a 1,000‑node web cluster with load balancing and failover.

SQL (MySQL) ≈ 1 K QPS per instance.

NoSQL (Redis) ≈ 20 K QPS per instance.

NoSQL (Memcached) ≈ 200 K QPS per instance.

Microservice decomposition aligns services with appropriate storage technologies, and data tables are designed to keep rows small and evenly distributed. Overall, the solution combines multi‑layer caching, sharding, read/write splitting, message queues, and careful capacity planning to achieve high scalability, availability, and performance for a billion‑user social platform.