System design crash course

The four signals you are scored on

Almost every rubric at every company reduces to the same four signals. Keep them in mind the entire session.

• Problem solving — do you turn a vague prompt into a concrete, bounded problem before designing?
• Solution design — is your architecture coherent, does every component earn its place?
• Technical excellence — do your deep dives show you understand the hard parts, not just the boxes and arrows?
• Communication — can the interviewer follow your reasoning, and do you bring them along?

The most common failure mode

Candidates lose the interview in the first five minutes by jumping straight to drawing boxes. Interviewers score scoping heavily: a senior candidate who designs the wrong system confidently scores worse than one who designs a simple system deliberately.

1. Requirements (5 minutes)

Separate functional requirements (what the system does) from non-functional requirements (how well it must do it: scale, latency, consistency, availability). Ask questions until you can state the system in one sentence. Then say it back: "So we're building X that does A and B, at the scale of C, where D matters more than E."

• Functional: the 2–3 core user flows. Cut everything else explicitly.
• Non-functional: read-heavy or write-heavy? Strong or eventual consistency? Latency budget?
• Out of scope: say it out loud — it signals seniority.

2. Entities and API (5 minutes)

Name the core data entities (User, Tweet, Order) and the 2–4 API endpoints that satisfy the functional requirements. This is a contract with the interviewer: everything you design later exists to serve these.

3. High-level design (10–15 minutes)

Draw the simplest architecture that satisfies the requirements: client, load balancer, application servers, database. Add components one at a time, each time saying why. Never add a box without a reason — "we need a cache here because reads are 100:1 over writes and we need sub-100ms latency."

4. Deep dives (15–20 minutes)

The interviewer will pick the hard part: "How does the feed fan-out work?" "What happens when a shard dies?" This is where levels are decided. Go deep on one or two areas rather than shallow on five. Quantify as you go.

Load balancers

Distribute traffic across stateless application servers so you can scale horizontally and survive server failures. Key points: health checks, L4 (transport, fast) vs L7 (application, content-aware routing), and that stateless app servers are what make this work.

Caches

Store hot data in memory (Redis, Memcached, or in-process) to take load off the database and hit latency budgets. Know cache-aside vs write-through, TTLs, eviction, and the classic failure modes: cache stampede, hot keys, and stale data.

• Use when: read-heavy workloads, expensive computations, hot entities.
• Cost: staleness, extra infrastructure, invalidation complexity.

Databases — SQL vs NoSQL

Pick based on access patterns, not fashion. Relational (Postgres) for structured data, joins, and transactions. NoSQL (DynamoDB, Cassandra) for massive scale, simple key-based access, and flexible schemas. Be ready to defend your choice against the alternative.

Replication and sharding

Replication (leader-follower) gives you read scale and failover; know sync vs async replication and the stale-read tradeoff. Sharding splits data across machines when one node can't hold the write volume or dataset; know the pain points — resharding, hot shards, and losing cross-shard joins.

Message queues and streams

Kafka, SQS, RabbitMQ decouple producers from consumers and turn spiky synchronous work into smooth asynchronous work. Use for fan-out, background jobs, and absorbing write bursts. Cost: eventual consistency and exactly-once delivery being harder than it sounds.

CDNs and blob storage

Static assets and media do not belong in your database or on your app servers. Blob storage (S3) holds the bytes; a CDN caches them at the edge near users. Say "client uploads directly to S3 via a presigned URL" and you've signaled real-world experience.

The numbers worth memorizing

Estimate QPS, storage growth, and bandwidth at the start of the design, and revisit them during deep dives: "at 50K writes per second, a single Postgres leader won't keep up, so we shard."

• 1M requests/day ≈ 12 QPS; 100M requests/day ≈ 1,200 QPS
• Read:write ratio drives caching and replication decisions
• 1 KB × 1M objects ≈ 1 GB — storage math is usually this simple
• Memory is ~100x faster than SSD, ~100,000x faster than network round trips across regions

Let the numbers decide

The point of estimation is not arithmetic — it's justification. "We'll need a cache" is an opinion. "At 100K QPS with a 100:1 read ratio, hitting the database on every read means 100K queries a second; a cache absorbing 99% of that gets us to 1K" is an answer.

Consistency vs availability

When the network partitions, you choose: refuse writes to stay consistent (CP) or keep accepting and reconcile later (AP). Banking ledgers lean CP; social feeds lean AP. Know what eventual consistency means for the user experience, not just the theorem.

Latency vs durability

Acknowledging a write after one replica is fast but can lose data; waiting for three replicas across regions is durable but slow. Message queues and async replication live in exactly this tradeoff space.

Push vs pull (fan-out)

The classic feed-design question. Push (fan-out on write) makes reads fast and writes expensive — and explodes for celebrities. Pull (fan-out on read) is the inverse. Hybrid is what real systems do. This pattern — write-time vs read-time work — recurs everywhere.

SQL vs NoSQL, restated

Transactions and joins vs horizontal scale and schema flexibility. If you picked one, the interviewer will argue the other. Have the counter-argument ready: "NoSQL would scale more easily, but our access patterns need joins and the scale doesn't justify giving them up yet."

Designing before scoping

Drawing boxes in the first two minutes. Fix: spend the first five minutes only on requirements, and state the system back in one sentence before touching the diagram.

Buzzword soup

Naming Kafka, Redis, Kubernetes, and Cassandra without a reason each. Fix: every component gets a "because" clause tied to a requirement or a number.

A diagram with no depth

A beautiful high-level design where you can't explain how any single box actually works. Fix: for every technology you draw, be able to answer "how does it do that?" one level down.

Ignoring failure

No interviewer lets a design pass without asking "what breaks?" Fix: walk your own diagram and find the single points of failure before they do — database failover, cache loss, queue backlog, hot partitions.

Going silent

Thinking quietly for three minutes reads as stuck. Fix: narrate your reasoning continuously, including the options you're rejecting — rejected options are scored too.