Bird
Raised Fist0

How to Estimate QPS, DAU, Storage, and Bandwidth for Any System

HLDmediumInterview freq: high
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
🏗️
How to Estimate QPS, DAU, Storage, and Bandwidth for Any System
Master concrete scale estimations to drive architecture decisions and defend trade-offs
mediumSystem Design Interview ApproachFreq: high
⚙️
Functional Requirements
  • Estimate Daily Active Users (DAU) based on given user base and activity patterns
  • Calculate write and read QPS from DAU and user behavior assumptions
  • Derive storage requirements including data retention and replication overhead
  • Compute bandwidth needs for inbound and outbound data flows
  • Estimate server counts for critical components based on throughput and latency SLAs
  • Provide clarifying questions to refine assumptions and scope
📊
Non-Functional Requirements
  • Support up to 2 billion DAU
  • Handle peak write QPS of approximately 925,000 messages per second
  • Ensure 99.99% availability for critical data ingestion and retrieval
  • Maintain 100ms P99 latency for read and write operations
  • Design for data retention of at least 30 days with replication factor of 3
❓
Clarifying Questions to Ask
  • What is the average number of messages or events generated per user per day?
  • What is the average size of each message or event in bytes?
  • What is the expected read-to-write ratio for the system?
  • What is the data retention period and replication factor for durability?
  • Are there peak traffic hours or is the load evenly distributed?
  • What are the latency and availability SLAs for reads and writes?
Out of Scope
✗ Detailed UI/UX design for user-facing components
✗ Authentication and authorization mechanisms
✗ Specific business logic beyond data volume and throughput estimation
✗ Real-time analytics or machine learning pipelines
📌
Assumptions
  • DAU = 2,000,000,000 users
  • Average messages per user per day = 40
  • Average message size = 100 bytes
  • Data retention = 30 days
  • Replication factor = 3
⚡
QPS Calculation
write qps2,000,000,000 × 40 / 86,400 ≈ 925,926 msg/sec
peak write qpsAssuming 2× peak factor: 925,926 × 2 = 1,851,852 msg/sec
read qpsAssuming 5 reads per write: 925,926 × 5 = 4,629,630 reads/sec
💾
Storage Estimate
daily storage2,000,000,000 × 40 × 100 bytes = 8,000,000,000,000 bytes = 8 TB/day
retention storage8 TB/day × 30 days = 240 TB
with replication240 TB × 3 = 720 TB total storage
🖥️
Server Estimate
write ingestion serversAssuming each server handles 10,000 writes/sec, need 1,851,852 / 10,000 ≈ 186 servers
read serving serversAssuming each server handles 20,000 reads/sec, need 4,629,630 / 20,000 ≈ 232 servers
🏗️
Architecture Diagram
Architecture Diagram
          +----------------------+
          |      Clients         |
          +----------+-----------+
                     |
                     v
          +----------------------+
          |  API Gateway (Nginx) |
          +----------+-----------+
                     |
                     v
          +----------------------+
          | Write Ingestion Layer |
          |  (Kafka Producers)   |
          +----------+-----------+
                     |
                     v
          +----------------------+
          |    Kafka Cluster     |
          +----------+-----------+
                     |
                     v
          +----------------------+
          |  Processing Workers   |
          |  (Kafka Consumers)    |
          +----------+-----------+
                     |
                     v
          +----------------------+
          |   Cassandra Cluster   |
          +----------+-----------+
                     |
                     v
          +----------------------+
          |   Read Serving Layer  |
          |   (Cassandra + Redis) |
          +----------------------+
🧩
Components
API Gateway (Nginx)
Handles client requests, load balances writes and reads to backend services
Why thisNginx provides high throughput, low latency reverse proxy with mature load balancing
Why notAWS ALB is managed but adds latency and less control over routing rules at scale
Kafka Cluster
Durable, scalable message queue for write ingestion buffering and decoupling producers from consumers
Why thisKafka supports high throughput (millions of msgs/sec), partitioning, and replication for durability
Why notRabbitMQ lacks horizontal scalability and throughput at 1M+ msg/sec scale
Processing Workers (Kafka Consumers)
Consume messages from Kafka, perform transformations, and write to storage
Why thisKafka consumer groups enable parallel processing with exactly-once semantics
Why notDirect writes from producers to DB cause backpressure and reduce availability
Cassandra Cluster
Primary storage for time-series message data with high write throughput and linear scalability
Why thisCassandra's wide-column model and tunable consistency fit high write QPS and 30-day retention
Why notPostgreSQL requires complex manual sharding and does not scale linearly at 925K writes/sec
Read Serving Layer (Cassandra + Redis)
Serve low-latency reads using Redis cache backed by Cassandra for durability
Why thisRedis TTL natively expires stale data, enabling sub-millisecond lookups; Cassandra ensures data persistence
Why notMemcached lacks persistence and TTL management, increasing cache staleness risk
🔄
Data Flow
1
Clients → API Gateway
Send write/read requests
API Gateway routes requests to ingestion or read layers
2
API Gateway → Kafka Producers
Publish write messages to Kafka topics
Decouples client writes from storage latency
3
Kafka Cluster → Processing Workers
Consume messages for processing and enrichment
Enables scalable parallel processing
4
Processing Workers → Cassandra Cluster
Write processed messages to Cassandra
Stores data with replication and retention
5
Clients → Read Serving Layer
Read requests served from Redis cache or Cassandra fallback
Ensures low latency and high availability

Practice

(1/5)
1. In a bulkhead-isolated microservice architecture, at step 4 in the request trace, the Bulkhead Manager checks the thread pool status before dispatching a request. What happens if the thread pool is fully occupied?
easy
A. The request is queued indefinitely until a thread becomes available
B. The request is forwarded to a fallback service without delay
C. The Bulkhead Manager increases the thread pool size dynamically to handle the request
D. The Bulkhead Manager rejects the request immediately to prevent resource exhaustion

Solution

  1. Step 1: Trace Bulkhead Manager behavior at Step 4

    When the thread pool is full, queuing indefinitely (A) risks resource exhaustion. Dynamic resizing (D) breaks isolation guarantees. Forwarding to fallback (C) is a separate mechanism.

  2. Step 2: Understand bulkhead failure containment

    Rejecting requests immediately (B) prevents overload and contains failure blast radius.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Bulkhead rejects requests when resource limits reached [check]
Hint: Reject requests when bulkhead resources are exhausted [check]
Common Mistakes:
2. In the Pastebin system request flow, at Step 4 the Expiration Worker scans stored snippets to remove expired entries. What state does the worker observe for a snippet whose TTL just expired but is still being accessed by a user?
easy
A. The snippet is immediately deleted and inaccessible to the user
B. The snippet remains accessible until the worker completes the deletion batch
C. The snippet is marked as expired but still served until a manual cleanup
D. The snippet is locked and user requests are blocked until deletion finishes

Solution

  1. Step 1: Trace Expiration Worker behavior at Step 4

    The worker deletes expired snippets in batches; deletion is not instantaneous upon TTL expiry.

  2. Step 2: Understand user access during deletion

    Until deletion completes, the snippet remains accessible; no locking or blocking occurs.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Batch deletion delays snippet removal, keeping it accessible briefly [check]
Hint: Expiration deletion is batch-based, not instant [check]
Common Mistakes:
3. For detecting anomalies in high-volume metric streams with low latency, which architecture is better suited and why?
medium
A. Batch processing with hourly aggregation to reduce noise and improve accuracy
B. Polling external ML service every 10 minutes to classify anomalies asynchronously
C. Streaming anomaly detection using windowed statistical models for near real-time alerts
D. Threshold-based alerts combined with manual tuning to approximate anomalies

Solution

  1. Step 1: Analyze latency and volume constraints

    High-volume streams require low-latency detection to be actionable.

  2. Step 2: Match architecture to constraints

    Streaming anomaly detection with windowed models processes data continuously, enabling near real-time alerts, unlike batch or polling which add latency.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Streaming windowed models -> low latency anomaly detection [check]
Hint: High volume + low latency -> streaming anomaly detection [check]
Common Mistakes:
4. You must design a system that processes high-volume event streams with strict ordering per customer but can tolerate some message duplication. Which approach is best?
medium
A. Partition the topic by customer ID and use multiple consumers in a group
B. Use Kafka with exactly-once semantics and idempotent producers
C. Use multiple topics per customer to isolate streams
D. Use a single Kafka topic with one partition to guarantee ordering

Solution

  1. Step 1: Evaluate ordering and throughput needs

    Single partition guarantees ordering but limits throughput severely.

  2. Step 2: Assess partitioning by customer ID

    Partitioning by customer ID preserves ordering per customer and allows parallel consumption.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Partition key + consumer group balances order and scale [check]
Hint: Partition by customer ID for order and parallelism [OK]
Common Mistakes:
5. At 10x scale, which component in a durable messaging system fails first and why?
hard
A. The database crashes due to increased write volume
B. Kafka brokers fail because partition leaders become overloaded with replication and disk I/O
C. Delivery workers fail because they cannot keep up with message fan-out
D. Chat servers fail because WebSocket connections are stateful and cannot be resharded

Solution

  1. Step 1: Identify bottlenecks at 10x scale

    Databases (A) can be scaled with sharding; delivery workers (C) can be horizontally scaled; chat servers (D) are stateful but not the first to fail.

  2. Step 2: Analyze Kafka broker load

    Kafka brokers handle replication and disk I/O per partition leader; at 10x scale, leaders become overloaded causing broker failures first.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Kafka partition leaders overloaded with replication cause first failure at scale [check]
Hint: Kafka partition leaders hit replication I/O bottleneck first at scale [check]
Common Mistakes:
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard