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
45 min · senior
senior

You are designing a capacity planning tool for a startup with 50 million daily active users (DAU). The system must provide accurate estimates of QPS, storage, and bandwidth for various product features under real-world constraints. The startup requires end-to-end encryption for user data, offline delivery support, and a P99 latency under 200ms for API responses.

Constraints
  • End-to-end encryption of user data at rest and in transit
  • Support offline delivery with eventual consistency
  • P99 API latency under 200ms
  • Estimate must handle bursty traffic with 3x peak factor
  • Data retention for 90 days with efficient storage
  • Support multi-region deployment with bandwidth cost optimization
📋
Guided Steps
1/5
Step 1
Define Metrics and Data Sources
What key metrics and data sources will you collect to estimate QPS, DAU, storage, and bandwidth?
💡 Hint
Think about user activity logs, feature usage, and network traffic data that reflect real system load.
Key Decision
Use Kafka as the ingestion pipeline for real-time user activity logs and feature usage events to capture high-throughput data streams.
Interviewer Expectation
Mid: Names Kafka for ingestion. Senior: Explains why Kafka partitions by user_id to maintain ordering and scale to 50M DAU with 3x peak bursts.
⚠️Common Wrong Answer
Using HTTP polling for data ingestion - causes high overhead and cannot handle bursty 50M DAU traffic.
Step 2
Estimate QPS and DAU from Raw Data
How will you process raw event data to estimate QPS and DAU accurately under encryption constraints?
💡 Hint
Consider stream processing frameworks that support encrypted data and windowed aggregations.
Key Decision
Use Apache Flink with encrypted data support to perform windowed aggregations on Kafka streams, computing QPS and DAU per feature in near real-time.
Interviewer Expectation
Mid: Mentions Flink for stream processing. Senior: Details how Flink’s event-time windows handle out-of-order encrypted events and maintain P99 latency under 200ms.
⚠️Common Wrong Answer
Batch processing with Hadoop - introduces high latency and cannot meet P99 < 200ms SLA.
Step 3
Storage Design for Estimates and Raw Data
What storage systems will you use to store raw encrypted data and aggregated estimates for 90 days?
💡 Hint
Separate cold and hot storage; consider encryption at rest and efficient range queries.
Key Decision
Store raw encrypted events in Amazon S3 with server-side encryption for cost-effective cold storage; store aggregated estimates in Cassandra with partition key by feature_id and date for fast range queries.
Interviewer Expectation
Mid: Names S3 and Cassandra. Senior: Explains why S3 is cost-effective for cold encrypted data and Cassandra’s partitioning enables O(1) range scans for daily estimates.
⚠️Common Wrong Answer
Using a single relational database for all data - leads to scalability bottlenecks and high cost at 50M DAU scale.
Step 4
Bandwidth Estimation and Multi-Region Optimization
How will you estimate bandwidth usage and optimize for multi-region deployments?
💡 Hint
Consider data replication costs and differential compression techniques.
Key Decision
Use Prometheus with custom exporters to monitor bandwidth metrics per region; apply delta encoding compression before cross-region replication to reduce bandwidth costs.
Interviewer Expectation
Mid: Mentions Prometheus for monitoring. Senior: Explains how delta encoding reduces cross-region bandwidth by 60% and how metrics guide replication frequency adjustments.
⚠️Common Wrong Answer
Ignoring bandwidth costs in multi-region setups - leads to unexpectedly high cloud egress charges.
Step 5
API Design for Estimation Service
Design 3 core API endpoints for submitting usage data, querying estimates, and receiving capacity alerts.
💡 Hint
Think about secure ingestion, flexible querying with filters, and push notifications or webhooks for alerts.
Key Decision
POST /usage to ingest encrypted usage data via HTTPS; GET /estimates with query params for time range and feature; Webhook subscription endpoint /alerts for capacity breach notifications.
Interviewer Expectation
Mid: Defines basic REST endpoints. Senior: Details encryption in transit, pagination for large queries, and webhook retry policies for reliable alert delivery.
⚠️Common Wrong Answer
Using HTTP polling for alerts - causes high latency and unnecessary load on clients and servers.
🔌
API Design Challenge
Sketch 3 core API endpoints for the estimation system that allow clients to submit usage data, query estimates, and receive notifications on capacity alerts.
Hints
  • How does the client submit real-time or batch usage metrics securely?
  • How does the client query estimates with filters like time range and feature type?
  • How does the system notify clients about threshold breaches or anomalies?
📊
Scoring Rubric
▼ Show
Must Have - 60%
  • Use Kafka for scalable ingestion of 50M DAU encrypted events
  • Stream processing with Apache Flink to meet P99 < 200ms latency
  • Separation of cold and hot storage using S3 and Cassandra with encryption
  • API design supporting secure ingestion, querying, and alerting
Good to Have - 30%
  • Bandwidth monitoring with Prometheus and multi-region optimization
  • Compression techniques to reduce replication bandwidth costs
  • Partitioning strategies in Cassandra for efficient range scans
Bonus - 10%
  • Detailed retry and backoff strategies for webhook alert delivery
  • Consideration of burst traffic with 3x peak factor in capacity planning
Anti-patterns to Avoid
HTTP polling for ingestion or alerts causes excessive load and latency spikes, leading to system collapse under 50M DAU traffic
Batch-only processing fails to meet P99 latency SLA for real-time estimates, resulting in stale data and poor user experience
Using relational databases for raw event storage leads to scalability bottlenecks and high costs at 50M DAU scale
Ignoring encryption at rest and in transit violates security constraints and risks data breaches
Single-region deployment without bandwidth optimization incurs high cloud egress costs and latency for global users
No partitioning strategy in storage causes hotspots and slow queries at scale, degrading system performance
✅
Model Answer
▼ Reveal

The system uses Kafka for encrypted event ingestion, Apache Flink for real-time QPS and DAU estimation, S3 and Cassandra for encrypted storage, and Prometheus for bandwidth monitoring. APIs support secure data submission, querying, and alert notifications with P99 latency under 200ms.

Key Decisions
  • Kafka partitions by user_id to maintain ordering and scale to 50M DAU with 3x peak bursts
  • Apache Flink uses event-time windowing to handle out-of-order encrypted events and maintain P99 latency under 200ms
  • Raw encrypted events stored in Amazon S3 with server-side encryption for cost-effective cold storage
  • Aggregated estimates stored in Cassandra partitioned by feature_id and date for efficient range queries
  • Prometheus with custom exporters monitors bandwidth per region; delta encoding compression reduces cross-region replication bandwidth by 60%
  • API design includes POST /usage for encrypted data ingestion over HTTPS, GET /estimates with pagination and filters, and webhook-based /alerts with retry and backoff policies
  • Kafka for high-throughput, partitioned ingestion of encrypted user activity streams
  • Apache Flink for low-latency, windowed stream processing with event-time semantics
  • Amazon S3 with server-side encryption for cost-effective cold storage of raw data
  • Cassandra with feature_id and date partition keys for efficient range queries on estimates
  • Prometheus with custom exporters to monitor bandwidth and system metrics per region
  • Delta encoding compression to reduce cross-region bandwidth replication costs
  • HTTPS REST API with encrypted payloads for secure data ingestion and querying
  • Webhook-based alerting system with retry and backoff policies for capacity notifications

Practice

(1/5)
1. In a distributed database, at Step 4 the coordinator node receives conflicting writes from two partitions during a network split. What state does the coordinator enter immediately after Step 4?
easy
A. Coordinator marks the writes as conflicting and delays commit until partition heals
B. Coordinator commits both writes immediately to maintain availability
C. Coordinator rejects all writes to maintain consistency during partition
D. Coordinator forwards writes to a third node to resolve conflicts synchronously

Solution

  1. Step 1: Trace coordinator behavior at Step 4

    The coordinator detects conflicting writes from partitions and cannot commit both safely.

  2. Step 2: Understand conflict resolution

    It marks writes as conflicting and delays commit until partitions heal to avoid inconsistency.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Coordinator defers conflicting writes until partition resolution [check]
Hint: Coordinator delays conflicting writes until partition heals [check]
Common Mistakes:
2. A system needs to serve AI code completions with sub-100ms latency while ensuring up-to-date code context. Which component is best suited to provide fast, low-latency retrieval of relevant code snippets?
easy
A. A relational database with complex SQL queries for code indexing
B. An in-memory vector search engine with approximate nearest neighbor (ANN) indexing
C. A distributed file system storing raw code files for batch processing
D. A message queue to buffer code snippet requests before processing

Solution

  1. Step 1: Identify low-latency retrieval need

    Relational DBs (A) have high query latency for vector similarity; distributed file systems (C) are for storage, not fast retrieval; message queues (D) buffer requests but don't serve retrieval.

  2. Step 2: Recognize vector search role

    ANN-based in-memory vector search engines (B) provide fast approximate nearest neighbor lookups, ideal for sub-100ms latency code snippet retrieval.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    ANN vector search enables fast similarity queries [check]
Hint: Vector search engines excel at fast similarity retrieval [check]
Common Mistakes:
3. A file synchronization system must efficiently detect and upload only changed parts of large files to minimize bandwidth. Which component is primarily responsible for identifying these changed chunks before upload?
easy
A. The server-side storage engine that compares full file versions to detect differences
B. The client-side chunking module that splits files and computes hashes for delta detection
C. The network layer that compresses data during transmission
D. The metadata database that stores user permissions and file ownership

Solution

  1. Step 1: Identify chunking responsibility

    The client-side chunking module splits files into chunks and computes hashes to detect which chunks have changed, enabling delta uploads.

  2. Step 2: Eliminate other components

    The server-side storage engine stores chunks but does not perform delta detection; network layer compresses data but doesn't detect changes; metadata DB manages permissions, unrelated to chunk detection.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Client chunking detects changed parts before upload [check]
Hint: Client chunking hashes detect changes before upload [check]
Common Mistakes:
4. Without a distributed lock service, what exactly breaks when two instances concurrently update a shared configuration in a distributed system?
medium
A. Both updates succeed but the system crashes due to race conditions
B. One update overwrites the other silently, causing inconsistent configuration state
C. The system automatically queues updates and applies them sequentially
D. Updates are rejected by the database due to conflicting transactions

Solution

  1. Step 1: Understand lack of distributed locking

    Without distributed locks, concurrent updates can overwrite each other silently (B), causing inconsistent state.

  2. Step 2: Evaluate other options

    System does not automatically queue updates (C) without explicit coordination. Database rejecting conflicting transactions (D) depends on isolation level and may not prevent lost updates. System crash (A) is unrelated.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Concurrent updates without locks -> silent overwrite [check]
Hint: No lock -> silent overwrite, no automatic queuing [check]
Common Mistakes:
5. At 10x scale, which component in a consistent hashing system with virtual nodes is most likely to fail first and why?
hard
A. The physical nodes, because they cannot handle increased key storage and request load
B. The token metadata service, due to increased complexity managing many virtual nodes and frequent updates
C. The network, because consistent hashing increases network chatter exponentially with scale
D. The client-side hash function, as hashing large key sets becomes computationally infeasible

Solution

  1. Step 1: Identify scaling bottlenecks

    Physical nodes scale horizontally; network and hash function scale well with optimizations.

  2. Step 2: Analyze token metadata service

    Managing many virtual nodes and frequent node changes increases metadata complexity and update frequency, causing bottlenecks.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Token metadata service complexity grows fastest, causing first failure [check]
Hint: Token metadata complexity grows fastest 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