Common System Design Interview Mistakes and How to Fix Them

Many candidates start drawing components in the first minute. That feels productive, but it usually creates an answer for the wrong product. A chat app for ten-person teams and a global consumer messenger have different fan-out, storage, moderation, and availability needs.

Fix it by forcing the first five minutes into scope, non-goals, and success metrics. Say what version you are designing and what you are intentionally deferring.

A number that never changes a design choice is decoration. If you estimate 50k writes per second, the next sentence should explain how that affects partitioning, batching, queues, database selection, or regional topology.

• Bad: "We have 100M users, so we need scale."
• Better: "At peak, writes are 20k/s. A single primary database is the bottleneck, so I will partition writes by tenant and keep the read model denormalized."
• Best: connect the estimate to a limit, mitigation, and monitoring signal.

Architecture boxes are not enough. For each component, name what it owns, what data it stores, what API it exposes, how it fails, and how it scales. If two services can write the same entity, you have created a consistency problem that needs an answer.

A strong answer sounds less like a catalog of tools and more like a map of responsibilities.

Reliability is not a bonus section at the end. Every system design answer should name likely failures: slow downstreams, duplicate retries, queue backlog, hot partitions, cache stampede, regional outage, schema migration, or abuse traffic.

The fix is to thread reliability through the design. When you add a queue, discuss dead-letter behavior. When you add retries, discuss idempotency. When you add a cache, discuss invalidation and stale reads.