Software Architecture & System Design.
Interview cheat sheet.

This is the run-of-show for the system design round: what to say, what to decide, and the numbers to have ready. Skim it the night before; use the focused sheets in this category for depth on any single topic.

The interview is a structured conversation with a clock. Interviewers grade how you drive it, not just what you draw. Follow this timeline and you will never run out of time with an empty whiteboard.

Two habits that raise every phase: think out loud (a silent minute feels like five), and check in ("does this match what you had in mind, or should I go deeper here?").

The first five minutes are free points. Interviewers deliberately give vague prompts to see if you ask. Ask these, then write the answers in a corner of the board.

1. Who uses this and what is the core action? (One sentence. "Users shorten a URL and share it.")
2. How many users? Daily actives, not registered accounts.
3. Read-heavy or write-heavy? Ask for the ratio. This one answer drives caching, replicas, and DB choice.
4. How fast must it feel? Interactive (under ~200 ms) vs background (seconds is fine).
5. How correct must it be? Is stale data acceptable for a few seconds, or never (money, inventory)?
6. What scale of data? Size per item and how long we keep it.
7. Any hard constraints? Regions, compliance, mobile-only, budget.
8. What is explicitly out of scope? Say it out loud so you are not graded on it.

When the interviewer says "you decide": decide, state it as an assumption, and move on. "I'll assume 10M daily actives and 100:1 reads to writes - tell me if you want different numbers." Deciding quickly with stated assumptions reads as senior; fishing for hints reads as junior.

You need about six numbers and one method. Round aggressively - the goal is the right power of ten, not the right digit.

The shortcuts

The latency ladder

The only hardware numbers worth memorizing:

Worked example, 60 seconds

Photo app: 10M daily actives, each views 50 photos and uploads 2/day at 500 KB.

• Write QPS: 20M uploads / 100k sec = 200/sec, peak ~1,000/sec. Modest.
• Read QPS: 500M views / 100k sec = 5,000/sec, peak ~25,000/sec. Read-heavy: cache + CDN.
• Storage: 20M × 500 KB = 10 TB/day ≈ 3.7 PB/year. Object storage, not a database.

Close with a sanity check: "so this is a read-heavy system whose hard problem is storage and delivery, not write throughput." That sentence - math driving the design - is what the estimate phase is actually for.

Every design is the same dozen blocks arranged differently. For each one, know its one-line job, when to reach for it, and the trade-off to say out loud when you add it.

Rule of thumb: introduce a block only when a number or requirement demands it, and say which one. "At 25k reads/sec we need a cache" beats "let's add Redis" every time.

Say the senior line first: "I'd start with one Postgres instance - it handles more than people think - and here is what would force a change." Then choose by access pattern, not by fashion.

Signals that force a move off single-Postgres, in the order they usually arrive: read load (add replicas - still Postgres), dataset too big for one machine or write QPS in the tens of thousands (shard, or move that table to a wide-column store), one access pattern dominating (peel it off to a specialized store).

The trap to avoid: picking NoSQL "for scale" on day one, then discovering you need transactions and joins. Consistency needs decide too - money and inventory want ACID; likes and view counts don't.

Scale in this order. Each rung is cheaper and less complex than the next; climbing early is how systems get over-engineered. Name the rung, say what breaks next.

1. One bigger machine (vertical). Boring and correct. Breaks: hardware ceiling, single point of failure.
2. Stateless app servers behind a load balancer. Move sessions to Redis first. Breaks: the database is now the bottleneck.
3. Cache + CDN. Kill repeat reads before they hit the DB; 80-90%+ hit rates are normal. Breaks: writes and cache misses still land on one DB.
4. Read replicas. Writes go to the leader, reads to followers. Breaks: replication lag (read-your-own-writes bugs), and write volume still hits one machine.
5. Queues for async work. Take everything slow out of the request path; absorb spikes. Breaks: eventually nothing - until raw write volume does.
6. Shard the database. Split data across machines by a key (user ID: even spread, but cross-user queries scatter; geography: locality, but hotspots). Last resort: you lose joins and cross-shard transactions, and resharding is painful.

When asked "how does this scale?", walking this ladder with numbers is a complete answer. Saying "shard it" at rung one is a red flag - most systems retire before rung 6.

CAP in two sentences: network partitions will happen, so partition tolerance is not optional. During a partition you choose - keep answering with possibly stale data (availability) or refuse/wait until nodes agree (consistency).

Saying "pick 2 of 3" is the classic mistake; the real choice is C vs A, only during a partition. The follow-up worth knowing: PACELC - even with no partition, you still trade latency vs consistency (waiting for replicas to confirm is slower).

In the room, classify each piece of data: "the payment ledger needs strong consistency; the like counter can be eventual." Per-data-type reasoning is exactly what's being tested.

Idempotency, the favorite follow-up

Networks retry, so every operation may arrive twice. Design writes so a repeat is harmless: client sends a unique idempotency key, server stores processed keys and returns the saved result for duplicates. Any time you say "retry", say "idempotent" in the same breath.

Whatever you design, the next question is "what happens when X dies?" Have one sentence ready per pattern - the pattern name plus what it protects against.

• Timeouts: "Every remote call has a timeout - without one, a slow dependency freezes my whole thread pool."
• Retries with backoff and jitter: "Retry on failure, wait longer each time, add randomness so a thousand clients don't retry in sync and stampede the recovering service. Retries require idempotency."
• Circuit breaker: "After repeated failures, stop calling the broken service and fail fast; probe occasionally and close the circuit when it recovers. This stops cascading failure."
• Rate limiting: "Protect from abuse and overload. Token bucket allows short bursts; leaky bucket smooths to a constant rate; fixed window is simple but leaks 2x at window edges; sliding window fixes that for more memory."
• Graceful degradation: "Drop nice-to-have features under load instead of dying - serve the feed without recommendations, show cached prices."
• Redundancy: "No single point of failure: every tier has 2+ instances, the database has a failover replica, and I'd ask whether we need to survive a whole-region outage."

The complete answer to "what if the database goes down?" is a chain: "reads fail over to a replica; writes queue or fail fast behind a circuit breaker; the app degrades to cached data; alerts fire. We lose freshness, not the site."

Choose by the sentence that matches, and always answer sync vs async first: does the caller need the result to respond (sync), or can it acknowledge and process later (queue)? Async-by-default is a scalability superpower.

Common interview moment: "how do clients get updates?" Weak answer names a technology. Strong answer: "at this update frequency, polling every 30s is fine and simplest; if we need sub-second, I'd move to SSE - WebSockets only if clients also send in real time."

Most design questions are one of ~10 classics in costume. Each has a single insight that unlocks it and a trap that sinks candidates. Recognize the costume, lead with the insight.

Interviewers grade judgment, and judgment sounds like conditions and crossover points, not technology names. Same knowledge, different sentence, different level.

The pattern in every senior phrase: a number or condition, a default choice, and the trigger that would change it.

Interviewers see the same failure modes every week. Each has a recovery line - the round is graded on trajectory, so a caught mistake costs almost nothing.

The one-screen recall table. If you remember nothing else, remember these.

And the five sentences that carry the whole round: clarify before drawing; let the math pick the architecture; start simple and name the upgrade trigger; classify each data type's consistency; volunteer the failure story before being asked.