Bird
Raised Fist0

Common Mistakes Candidates Make in System Design Interviews

HLDmediumInterview freq: high
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
🏗️
Common Mistakes Candidates Make in System Design Interviews
Master the art of system design interviews by avoiding common pitfalls and demonstrating senior-level reasoning.
mediumSystem Design Interview ApproachFreq: high
Prerequisites:System Design FundamentalsCAP Theorem
⚙️
Functional Requirements
  • Understand and clarify system requirements before starting design
  • Estimate scale and throughput with concrete numbers
  • Design a scalable architecture with named technologies
  • Explain trade-offs and failure modes explicitly
  • Demonstrate clear data flow and component responsibilities
  • Ask clarifying questions to uncover hidden constraints
📊
Non-Functional Requirements
  • Support up to 2 billion daily active users (DAU)
  • Handle peak write throughput of ~925K writes/sec
  • Ensure 99.99% availability SLA
  • Maintain 100ms P99 latency for read and write operations
  • Design for 30-day data retention with replication
❓
Clarifying Questions to Ask
  • What is the expected daily active user count and peak concurrency?
  • What is the data retention period and replication factor?
  • Are there any strict latency or availability SLAs?
  • What are the read-to-write ratio and peak traffic patterns?
  • Is eventual consistency acceptable or is strong consistency required?
  • Are there any regulatory or compliance constraints?
Out of Scope
✗ Detailed UI/UX design considerations
✗ Specific programming language or framework choices
✗ Deep cryptographic protocol design
✗ End-to-end deployment and CI/CD pipelines
📌
Assumptions
  • 2 billion daily active users (DAU)
  • Each user generates 40 messages per day
  • Average message size is 100 bytes
  • Data retention period is 30 days
  • Replication factor is 3 for durability
⚡
QPS Calculation
write qps2B × 40 / 86400 ≈ 925,926 writes/sec
peak write qpsAssuming 2× peak factor: 925,926 × 2 ≈ 1,851,852 writes/sec
read qpsAssuming 10 reads per write: 925,926 × 10 ≈ 9,259,260 reads/sec
💾
Storage Estimate
daily storage2B × 40 × 100 bytes = 8 TB/day
retention storage8 TB × 30 days = 240 TB
with replication240 TB × 3 = 720 TB total storage
🖥️
Server Estimate
write pathKafka cluster with 100 brokers to handle 1.85M writes/sec (each broker ~20K writes/sec capacity)
read pathCassandra cluster with 200 nodes to handle 9.25M reads/sec (each node ~50K reads/sec)
🏗️
Architecture Diagram
Architecture Diagram
          +----------------+
          |   Client App   |
          +-------+--------+
                  |
                  v
          +-------+--------+
          |  API Gateway   |
          +-------+--------+
                  |
                  v
          +-------+--------+
          |  Kafka Cluster |
          +-------+--------+
                  |
                  v
          +-------+--------+
          | Cassandra DB   |
          +-------+--------+
                  |
                  v
          +-------+--------+
          |  Redis Cache   |
          +-------+--------+
                  |
                  v
          +-------+--------+
          | Notification   |
          |    Service     |
          +----------------+
🧩
Components
API Gateway
Entry point for client requests, handles authentication, rate limiting, and routing
Why thisNginx with Lua scripting for high throughput and flexible routing with sub-10ms latency
Why notAWS API Gateway is managed but adds unpredictable latency and cost at 2B DAU scale
Kafka Cluster
Durable, scalable write-ahead log for ingesting all messages asynchronously
Why thisKafka supports 1M+ writes/sec per cluster with partitioning and replication for durability
Why notRabbitMQ lacks horizontal scalability and throughput at 1.85M writes/sec peak
Cassandra DB
Distributed wide-column store for storing messages with high write throughput and linear scalability
Why thisCassandra offers tunable consistency, high write throughput, and automatic sharding without single points of failure
Why notPostgreSQL requires manual sharding and cannot handle 925K writes/sec without complex scaling
Redis Cache
In-memory cache for hot data and presence information with sub-millisecond latency
Why thisRedis TTL natively expires stale presence without cron jobs - sub-millisecond lookup for read-heavy workloads
Why notMemcached lacks persistence and advanced data structures needed for presence and session management
Notification Service
Push notifications and alerts delivery to clients asynchronously
Why thisCustom microservice using gRPC for low-latency, reliable delivery with backpressure handling
Why notThird-party services like Firebase have rate limits and lack fine-grained control at 2B DAU scale
🔄
Data Flow
1
Client App → API Gateway
Send message or read request
API Gateway authenticates and rate limits requests
2
API Gateway → Kafka Cluster
Publish write requests asynchronously
Decouples ingestion from storage for high throughput
3
Kafka Cluster → Cassandra DB
Consume messages and persist to DB
Ensures durable storage with replication
4
Client App → Redis Cache
Read hot data or presence info
Sub-millisecond reads for active users
5
Cassandra DB → Redis Cache
Update cache asynchronously
Cache warm-up and invalidation
6
Kafka Cluster → Notification Service
Trigger notifications for new messages
Asynchronous push to clients
7
Notification Service → Client App
Deliver push notifications
Handles retries and backpressure
🗄️
messages
PK: user_id
message_iduser_idtimestampcontentmetadata
Stores user messages partitioned by user_id and clustered by timestamp for efficient range queries.
🗄️
user_presence
PK: user_id
user_idlast_active_timestatus
Tracks user presence status with partitioning by user_id and clustering by last active time.
🔌
POST /messages
Request
{
  "user_id": "string",
  "content": "string"
}
Response
{
  "message_id": "string",
  "status": "success|failure"
}
Endpoint to send a new message; returns message ID and status.
🔌
GET /messages
Request
{
  "user_id": "string",
  "start_time": "timestamp",
  "end_time": "timestamp"
}
Response
{
  "messages": "array of message objects"
}
Fetches messages for a user within a time range.
🔌
GET /presence
Request
{
  "user_id": "string"
}
Response
{
  "status": "online|offline|away",
  "last_active_time": "timestamp"
}
Retrieves the presence status of a user.

Practice

(1/5)
1. In a distributed counter system using sharded CRDTs, at Step 4 the Aggregator node merges shard states received from replicas. What is the Aggregator's state immediately after merging two shards with counts 100 and 150?
easy
A. The Aggregator state is the average of the two counts: 125, to smooth spikes
B. The Aggregator state is the maximum of the two counts: 150, to avoid double counting
C. The Aggregator state is the sum: 250, reflecting all increments
D. The Aggregator state resets to zero after merging to avoid stale data

Solution

  1. Step 1: Understand CRDT merge semantics for counters

    Sharded counters merge by summing counts from each shard to reflect total increments without double counting.

  2. Step 2: Apply merge to counts 100 and 150

    Sum is 250, representing combined increments from both shards.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    CRDT counters merge by summing shard values [check]
Hint: CRDT counters merge by summing shard counts [check]
Common Mistakes:
2. A distributed API rate limiter must enforce limits with minimal latency at the network edge. Which component is best suited to perform this enforcement?
easy
A. Centralized database that aggregates all request counts for global enforcement
B. Edge cache with local counters and periodic sync to central store
C. Batch job that processes logs every minute to update usage stats
D. Client-side SDK that tracks usage and blocks requests locally

Solution

  1. Step 1: Identify edge enforcement needs

    Enforcement must be low-latency and close to the client to avoid network round trips.

  2. Step 2: Evaluate options for latency and consistency

    Centralized DB (A) adds latency; batch jobs (C) are too delayed; client SDK (D) is untrustworthy. Edge cache with local counters (B) balances latency and eventual consistency.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Edge cache enforces limits locally with periodic sync [check]
Hint: Enforce limits close to client with local counters [check]
Common Mistakes:
3. In the file sync system's upload flow, at Step 4 the Delta Upload Worker receives chunk hashes from the client. What does the worker do when it finds a chunk hash already stored on the server?
easy
A. Skips uploading that chunk and marks it as already present
B. Queues the chunk for re-chunking to optimize storage
C. Deletes the existing chunk and replaces it with the new one
D. Requests the client to resend the chunk data to verify integrity

Solution

  1. Step 1: Trace Delta Upload Worker behavior at Step 4

    When the worker finds a chunk hash already stored, it skips re-uploading the chunk to save bandwidth and marks it as present.

  2. Step 2: Eliminate incorrect behaviors

    Requesting resend wastes bandwidth; deleting existing chunks breaks deduplication; re-chunking is unrelated to upload step.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Delta Upload Worker skips existing chunks to avoid redundant upload [check]
Hint: Skip chunks with known hashes to save bandwidth [check]
Common Mistakes:
4. If the Kafka cluster used for fan-out events crashes and loses the latest messages, what exactly breaks in the newsfeed delivery?
medium
A. The system falls back to synchronous push, increasing write latency
B. Posts published just before the crash are lost; followers never see them
C. Followers receive duplicate posts due to re-delivery attempts
D. Delivery Workers block indefinitely waiting for missing messages

Solution

  1. Step 1: Understand Kafka's role in fan-out

    Kafka buffers fan-out events; Delivery Workers consume from Kafka to deliver posts asynchronously.

  2. Step 2: Trace failure impact

    If Kafka crashes and loses messages, Delivery Workers waiting on those messages block or stall, causing delivery delays.

  3. Step 3: Eliminate other options

    Duplicates (A) occur with retries, not loss. Lost posts (B) happen but are not the immediate failure mode. Fallback to synchronous push (D) is not automatic.

  4. Final Answer:

    Option D -> Option D

  5. Quick Check:

    Kafka crash causes Delivery Workers to block waiting for lost messages [check]
Hint: Kafka crash blocks Delivery Workers waiting for messages [check]
Common Mistakes:
5. At 10x scale, which component in a real-time chat system implementing CAP theorem fails first and why?
hard
A. The database fails first due to increased write amplification
B. The message queue fails first due to partition key hotspots causing uneven load
C. Chat servers fail first because WebSocket connections are stateful and cannot be resharded easily
D. The load balancer fails first due to inability to handle increased connection churn

Solution

  1. Step 1: Identify stateful bottleneck

    Chat servers maintain WebSocket connections statefully, limiting horizontal scaling.

  2. Step 2: Understand scaling impact

    At 10x scale, existing WebSocket connections cannot be moved, causing chat servers to saturate first.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Stateful WebSocket servers bottleneck scaling before DB or load balancer [check]
Hint: Stateful WebSocket servers bottleneck scaling first [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