System Design
The system-design section works differently from every other one. There is no single right answer here — there is a right line of reasoning. The interviewer is not watching for whether you said "Kafka"; they are watching for whether you derived the need for a queue from numbers you computed yourself. The whole topic rests on one skill — turning a vague "design a news feed" into a concrete set of constraints, and deriving the architecture from those constraints. A candidate who starts from technologies is designing in a vacuum, and it shows within the first minute.
Python gives you no discount here and adds a few traps of its own. The GIL means one process occupies one core, so "horizontal scaling" already starts inside a single machine — gunicorn with eight workers is eight independent processes, and any module-level cache, counter or scheduler exists in eight copies rather than one. After that come exactly the same traps as in any other language — session state in local memory, a shard key that creates a hotspot, a message redelivered after a worker crash, an RPC call without a timeout, and a metric with user_id in a label that kills the time-series database. The layers below take each mechanism apart in the order you actually apply them in a real interview.
Topic map
- The design-interview process — the five steps from clarifying requirements to bottlenecks, and why technologies are named last.
- Back-of-the-envelope estimation — deriving
RPS, storage and bandwidth from daily numbers, and why the peak multiplier matters. - Vertical vs horizontal scaling — the ceiling of one box, the statelessness requirement, and the ladder of techniques up to a billion users.
- Sharding and the shard key — splitting data vs replicating it, the resharding problem, and consistent hashing.
- Message queues and delivery guarantees — decoupling producer from consumer, at-least-once, idempotency and dead-letter queues.
- RPC — calling a procedure over the network — stubs, serialization, the leaky "just like a local call" abstraction, and the mandatory timeout.
- gRPC over HTTP/2 and protobuf — multiplexing, a binary schema keyed by field numbers, the four streaming modes, and when gRPC hurts.
- Observability — metrics, logs, traces — the three pillars, label cardinality, and what SLI and SLO actually mean.
Common mistakes and traps
| Mistake | Consequence |
|---|---|
Naming Redis, Kafka and Nginx before requirements are clear | The design is fitted to the stack instead of the problem, and no trade-off is backed by a number |
Using the daily request count as RPS, or sizing for the average only | An error of 86,400×; and capacity sized on the mean does not survive a peak an order of magnitude higher |
Expecting a load balancer to scale a stateful service | Session state in a node's local memory is lost when that node dies, and sticky sessions skew the load distribution |
Confusing sharding with replication | Replication copies the data whole and scales reads; sharding splits it and scales writes and volume too |
| Choosing a shard key for convenience rather than distribution | One hot shard takes almost all the traffic, and common queries turn into a scan across every shard |
| Counting on exactly-once delivery from the broker | The practical guarantee is at-least-once; without an idempotency key a retry charges the card twice |
| Calling a remote procedure with no timeout | A hung server pins the caller's workers and the failure cascades up the chain |
Putting user_id into a metric label | Cardinality explosion — millions of time series take down the metrics backend before the app itself falls over |
What interviews check
What is being probed first is process discipline. The junior questions sound like "what steps structure a design interview" and "what is a message queue" — naming the order (requirements, estimation, API, high-level sketch, detail with trade-offs) and not diving straight into code is enough. At middle level they ask what can be checked with numbers and definitions — vertical vs horizontal, sharding vs replication, what a capacity estimate consists of, what gRPC is and what it is built on. Answering "horizontal scaling makes every request faster" fails the question outright — nodes raise throughput, not the latency of a single request.
Senior level differs in that you are expected to give the order in which techniques are applied, not a list of them. The correct ladder is stateless services behind a load balancer first, then cache and CDN, then read replicas, a queue and rate limits, and only once all of that is exhausted — sharding and multiple regions. A candidate who opens with sharding pays the highest price for the earliest move. Two follow-ups are especially popular — "why must a service be stateless" and "how do metrics differ from logs and traces"; both filter out people who memorised a word list but never worked an incident by hand.