Engineering Atlas › System Design Interviews

Explaining your trade-offs out loud

13 min read · last reviewed 2026-10-17

Open in the interactive app: practice, quiz, mock interview →

In one minute

How it works

What interviewers are actually scoring

Rubrics at most large companies have a line called something like "tradeoff analysis" or "design judgement". Behind it sit three questions. Did the candidate see that there was a choice at all? Did they reason from the requirements they gathered, rather than from habit? Did they understand the second-order cost, such as operational burden or a failure mode that only appears at scale? "We'll use Cassandra" scores lower than "we need about 200k simple key writes per second and tolerate some staleness, so a leaderless wide-column store fits; we lose multi-row transactions, so the ledger stays in Postgres".

The axes that come up again and again

Most interview tradeoffs are one of these, sometimes wearing a costume.

A repeatable approach

  1. Before choosing, restate the requirement that decides it, ideally as a number: "feeds may lag by up to 5 seconds", "checkout must never double-charge", "p99 under 200 ms".
  2. Name two or three real options, not a straw man.
  3. Say what each option costs on the axis that matters, with a rough number.
  4. Pick one and state the mitigation for its weakness. Say how hard the choice is to undo: Amazon's 2015 shareholder letter separates one-way-door decisions, which deserve slow deliberation, from reversible two-way doors that should be made quickly (Amazon 2015 letter). A partition key is a one-way door; a cache TTL is a two-way door.
  5. State the trigger to revisit: "if writes exceed what one primary handles, which I'd estimate around 10k to 30k per second for this row size, we shard by user ID".

That fifth step is what separates staff answers. It shows you see the design as a point in time, not a final state.

Common mistakes

Down the stack

Layer 1The contract

A tradeoff statement is a contract you can test. "Reads may be stale by up to 2 seconds" means a read issued 2 seconds after a successful write must observe it. "RPO zero" means no acknowledged write is lost if any single node dies. "Available during an AZ failure" means a client in a surviving AZ gets a successful response within the timeout. Written this way, conflicts show early: RPO zero across regions with a 50 ms p99 write is impossible if the regions are 70 ms apart.

Layer 2The mechanism

Many consistency tradeoffs are tuned with quorums. With N replicas, a write waits for W acknowledgements and a read queries R replicas. If R + W > N, every read quorum overlaps every write quorum, so a read sees the latest acknowledged write (assuming versioned values and correct conflict handling). If 2W > N, two concurrent writes also overlap. Cassandra exposes this per request through consistency levels such as ONE, QUORUM and LOCAL_QUORUM, and resolves conflicting writes by last-write-wins timestamps, so it needs synchronised clocks (Cassandra docs). DynamoDB exposes it as eventually consistent versus strongly consistent reads, where eventually consistent reads cost half as much, and global secondary indexes support only eventual reads (DynamoDB docs). Its global tables used to be eventually consistent across regions only; they now also offer multi-Region strong consistency, which replicates each write synchronously to another region before acknowledging it, putting a cross-region round trip on every write (DynamoDB docs). Raft-based stores like etcd fix W at a majority and make reads linearizable by default, which sends them through Raft and adds latency; a client can ask for a serializable read instead, which is faster but may be stale (etcd docs). Postgres exposes the durability axis through synchronous_commit (off, local, remote_write, on as the default, remote_apply) and synchronous_standby_names, letting you choose per transaction, with SET LOCAL, whether to wait for a standby (Postgres docs).

Layer 3The machine

The costs behind these knobs are physical. A round trip inside one zone is about 0.1 ms on current cloud hardware and about 0.25 ms across a region (Napkin Math), with AWS keeping a region's zones within 100 km of each other (AWS); budget up to a millisecond or two under load. Across a continent it is 25 to 60 ms, and across an ocean 80 ms or more (Napkin Math), bounded below by light in fibre at roughly 200 km per ms. A durable write needs fsync, which on an NVMe SSD with power-loss protection can complete in tens of microseconds, but on consumer drives or network block storage often takes 0.5 to several ms; a 2026 cloud measurement put an 8 KiB write plus fsync at about 300 us against 2 us without it (Napkin Math). Memory costs on the order of tens of times more per GB than SSD, which is why caches are smaller than datasets. Each extra replica multiplies storage and write bandwidth. These numbers turn vague words like "slower" into the decisive comparison: a quorum write within a region adds a millisecond or two; a cross-region one adds a hundred.

Why it's built this way

Data must live on several machines to survive failure, so copies exist. Copies are separated by distance and distance costs time, so keeping them identical costs latency. Networks can partition, so a system must decide what an operation does when it cannot reach a majority. Because different operations care differently, good systems make the choice tunable per request rather than global. And because engineers are the scarcest resource, the simpler option often wins even when it is not the fastest.

Diagram

flowchart TD
    Q["Requirement as a number"] --> O["List 2-3 real options"]
    O --> C["Cost of each on the key axis"]
    C --> P["Pick one and name its cost"]
    P --> M["Mitigate the weakness"]
    M --> T["State the trigger to revisit"]
    T -->|"requirement changes"| Q

Worked example

The interviewer asks you to design a shopping cart for a retailer doing 50 million daily users, with peaks of about 20,000 cart writes per second, in two regions.

Option A is a single-primary relational store in one region with a cross-region async replica. Writes from the far region pay about 80 ms extra, and a region failure can lose a few seconds of carts. Option B is a multi-region leaderless store with LOCAL_QUORUM writes (N=3 per region, W=2): writes cost a local round trip of about 2 ms, but concurrent edits from two regions can conflict.

You say: "Carts are user-scoped and rarely edited from two places at once, and losing an item or showing a stale cart briefly is annoying but not costly. Latency and availability matter more than global ordering here, so I'll take option B and merge conflicts by unioning item adds and applying removes with timestamps. Checkout is different: payment and inventory decrement go through a strongly consistent store, because a double charge costs real money. If product later wants shared carts edited by several people at once, I'd revisit the merge rules."

That answer splits the system by requirement, names the cost, the mitigation and the trigger, in about 40 seconds.

In the wild

Trade-offs

OptionStrengthsWeaknessesChoose when
Strong consistency (majority quorum or leader reads)Simple reasoning, no stale readsExtra round trips, unavailable without a majorityMoney, inventory, uniqueness, locks
Eventual consistency (W=1 or async replicas)Low latency, stays up during partitionsStale reads, conflicts to resolveFeeds, counters, carts, profiles
Fan-out on writeCheap, fast readsWrite amplification, celebrity problemRead-heavy timelines with bounded fan-out
Fan-out on readCheap writesExpensive reads, tail latencyUsers with huge follower counts
Single-node simplicityEasy to run and reason aboutCeiling on scale and availabilityEarly stage, moderate load
Sharded or managed distributed storeScales horizontallyCross-shard queries, operational costLoad clearly beyond one node

Pitfalls in production

Leadership lens

Check yourself

  1. With N=5 replicas, which settings of R and W guarantee a read sees the latest acknowledged write, and what does W=5 cost?

    Show answer

    Any R and W with R + W > 5, such as R=3, W=3 or R=1, W=5. W=5 makes every write fail if any single replica is down, so write availability collapses.

  2. Why is "we chose CP" an incomplete answer?

    Show answer

    It only describes behaviour during a partition. Most of the time there is no partition, and the real everyday trade is latency against consistency, which needs its own answer.

  3. An interviewer pushes back on your eventually consistent feed. What should you do?

    Show answer

    Restate the staleness budget and its user impact, acknowledge the cost they raised, and change the design only if they change a requirement, for example a read-your-writes need you can meet with session routing.

  4. Why does a cross-region synchronous write rarely fit a 50 ms latency budget?

    Show answer

    Light in fibre needs roughly 1 ms per 100 km of round trip, so regions thousands of km apart add tens to over a hundred ms before any processing.

Sources and further study

Primary

Systems docs

Books

Other curricula

Watch

Free resources

Open in the interactive app: practice, quiz, mock interview →