skip to content

learn.smmeyer.devsystem-design14

menu

system-design/14

interview mode · studio · ~4h practice

Deep-dive tradeoff drills

outcome

Compare alternatives with a repeatable, evidence-based decision frame.

Plan a practice session · ~4h including exercises
Read + trace the worked example
25 min
Assignment + constraint variations
140 min
Timed drill + repeated explanations
55 min
Closed-book recall + self-review
20 min

This is a suggested practice budget, including drawing, variations, and repeated drills. Reading is the first block. Split the work across sessions and use the rubric to judge when to move on.

why this matters

Interviewers often push with ‘why not X?’ The goal is neither loyalty nor instant reversal. Define the decision dimensions, compare, choose for current constraints, and name the trigger that would change your mind.

coverage

  • Data: SQL/NoSQL, shard/replicate, strong/eventual.
  • Flow: queue/stream, push/pull, sync/async.
  • Computation: precompute/on-demand, stateful/stateless.
  • Transport: polling/WebSockets/SSE.
  • Topology: single/multi-region.
  • Strategy: build/buy, simplicity/scalability.

mental model

A strong tradeoff answer ends with a choice and a reversal trigger.

  1. 1 →Criteria

    What matters?

  2. 2 →Compare

    Benefits + costs

  3. 3 →Choose

    For this workload

  4. 4 →Trigger

    When to revisit

Read in numbered order: criteria → compare → choose → trigger.

lessons

01Use the FACT frame

Frame constraints, Alternatives, Consequences, Take a position. Compare on the few dimensions that matter: correctness, latency, scale, complexity, cost, and organizational fit.

A useful comparison begins with a deciding constraint. For an interactive status stream, suppose the browser only receives updates and must reconnect after drops. Compare SSE with WebSockets on one-way streaming, replay protocol, deployment support, and operational complexity. If no bidirectional requirement exists, SSE may meet the contract with less machinery. Adding bidirectional presence later could change the choice.

Write the alternatives fairly. Do not compare a carefully operated database with an imaginary alternative that has no backups or indexes. Include migration cost, operational knowledge, team size, and failure behavior alongside latency and throughput. A provider service can reduce infrastructure ownership while adding dependency, pricing, and capability constraints.

Finish with a decision, its main downside, and a measurable reversal trigger. “We choose one relational primary; revisit after representative tests show write saturation despite query and index fixes” is reviewable. “We might use NoSQL later” is not a trigger because it names neither the observed problem nor the condition under which the alternative helps.

  • Reject false binaries; hybrids are valid when justified
  • Do not hide operational cost
  • Say which requirement dominates

02Optimize for the current horizon

The simplest architecture that meets projected scale is usually strongest. Preserve seams for growth, but do not pay distributed-system costs before they buy something.

Architecture has a planning horizon. A system expected to handle 2k writes/s in the next year does not automatically benefit from the same topology as one handling 2M. Estimate the workload and growth, choose headroom, and state what is uncertain. If the growth estimate is weak, preserve a migration seam instead of implementing every future scale mechanism now.

Reversibility changes how much evidence you need. Changing a cache TTL is relatively cheap; moving an established data model across stores can be expensive. Spend more analysis on ownership, identifiers, and durable contracts, because other parts accumulate around them. Keep technology choices behind clear boundaries when that makes a later migration feasible.

A migration trigger needs a migration outline. If the trigger is tenant skew, explain whether you will split a tenant, add subkeys, or move it to dedicated capacity. Say how reads find the new owner and how writes avoid double ownership during transition. This demonstrates that simplicity today is a deliberate choice with a credible next step.

  • Scale estimates define the horizon
  • Operational familiarity is a valid factor
  • Migration triggers make simplicity credible

03Defend without rigidity

When challenged, restate the changed assumption and update the choice. A revised design is good reasoning, not failure. Keep the invariant stable even if mechanism changes.

An interviewer may change a premise rather than challenge your competence. “Now the customer requires zero accepted-write loss” invalidates an asynchronous failover assumption. Restate the new invariant, identify the affected write acknowledgement and promotion paths, and compare synchronous acknowledgement or refusing writes when the required replicas are unavailable.

Keep valid parts of the design. A changed durability promise does not automatically invalidate the API or blob layout. Draw the smallest necessary change, then discuss latency, availability, and cost consequences. A well-reasoned revision is stronger than defending an obsolete assumption or replacing every box without explanation.

Practice speaking the complete chain: deciding requirement → candidate mechanisms → choice → downside → evidence that would change it. Use a concrete workload, not a universal slogan. Once the listener understands that chain, stop and invite a deeper question. Concision becomes possible because the reasoning is complete, not because the important caveats were omitted.

  • Ask what constraint the interviewer is changing
  • Separate preference from requirement
  • Name the downside of your own choice first

worked example

Make a reversible choice with a clear switch trigger

A new service has two engineers, 50 writes/s, 99.9% availability needs, and no requirement to operate in multiple regions on day one.

  1. Compare a managed relational database with a custom distributed store on query fit, operational load, failure behavior, and cost.
  2. A managed relational service satisfies the stated access patterns while keeping ownership within the team's capacity.
  3. Record the alternative's real benefit, such as a needed multi-region write contract, along with the complexity it introduces now.
  4. Name the trigger for revisiting the choice: measured primary saturation after tuning, a concrete residency requirement, or a new availability contract.

Design decision: Choose the simplest option that meets the present contract and write down the evidence that would change the decision.

Limit: A switch trigger is a review point, not proof that a migration will be cheap. Preserve an exit path where it is affordable.

Teaching scenario · traffic, prices, and capacity values are illustrative.

assignment

Produce: Five short architecture decision records with an option table and reversal trigger.

Paper, a text editor, or a spreadsheet is enough. Model access and paid services are optional.

  1. Cover SQL/NoSQL, sync/async, SSE/WebSocket, single/multi-region, and build/buy using distinct stated workloads.
  2. For each, quantify one deciding constraint and one operational cost; argue the strongest case for the rejected option.
  3. Present decisions aloud, change one requirement, and revise the records rather than defending the original choice automatically.

Change a constraint

  • The team shrinks to one owner.
  • A new customer requires a capability the chosen provider lacks.

Self-review rubric

  • Each choice has a workload-specific reason.
  • The rejected option receives a fair comparison.
  • A measurable trigger identifies when to reconsider.

If a criterion is missing, revise that part of the artifact before rating your practice below.

Compare a sample artifact after your attempt

One defensible answer under these assumptions. Compare the reasoning and checks with your work; other designs can satisfy the same contract.

Two engineers operate a service at 50 writes/s with 99.9% availability and no initial multi-region requirement. These are example choices pending workload measurements.

ADR          choice / strongest alternative / revisit trigger
Store        relational / document layout / unmet measured query need
Async        outbox+worker / inline work / completion exceeds user deadline
Stream       SSE / WebSocket / required client-to-server live interaction
Topology     one region+recovery / multi-region / approved RTO or geography need
Ownership    managed service / self-run / capability or cost evidence changes
Each decision records downside, owner, test, and migration outline.

The deciding constraints favor operational simplicity, not a claim that 50 writes/s guarantees a particular database fits. A multi-region requirement would change topology and acknowledgement/recovery choices. A one-engineer team may strengthen the managed-service case; an unsupported customer capability can reverse it. Keep the current choice and trigger tied to evidence.

Check your artifact

  • Each ADR compares a credible alternative on the important dimensions.
  • The chosen option includes its main cost or failure limitation.
  • A trigger describes an observable condition and feasible migration, not merely a desire to use another technology.

A tempting mistake: A feature comparison with no contextual decision does not tell a reviewer what to build or when to reconsider it.

cumulative practice

Relay · build and evolve a private file service

Project brief

Keep one design document for Relay, a tenant-aware file service. Start with 100k daily users, ten downloads per user/day, 10k uploads/day, 1 MB typical bodies, 30-day retention, and a 5× download peak. Files are private to workspaces. Treat these as fictional planning assumptions. Later chapters add previews, recovery, regional constraints, compute, and an assistant. Record each change rather than replacing the earlier version; the final review combines the whole packet. These activities share the chapter's existing practice budget.

Keep one project document across this track. Reconstruct earlier reasoning before opening notes, then revise the same artifact. Use part of the assignment and review budget for this work. If you enter mid-course, sketch the earlier decisions first using the linked chapters.

Add to your project: Five Relay decision records with revision history.

Choose metadata storage, body caching, preview transport, regional ownership, and assistant control flow. Recall the strongest alternative for each. Now require zero accepted metadata-write loss on region failure; revise the affected ADR and state its latency/availability consequence.

Compare cumulative reasoning after your attempt

The regional acknowledgement and promotion protocol must change; an asynchronous replica alone cannot promise zero loss. Consider sufficiently durable cross-region acknowledgement or refusing writes when the required durable path is unavailable, then measure latency. Other decisions can stay if their invariants still hold. Keep the old assumption, new requirement, chosen protocol, downside, and migration/verification plan beside each other.

Keep your first attempt and revision together. If your answer differs, identify the assumption or mechanism that explains the difference before rating your recall.

senior signal

Answer ‘why X?’ in 45 seconds: criteria, 2 alternatives, decision, drawback, trigger. Concision signals command.

failure patterns

  • Feature-list comparisons with no decision
  • Claiming one technology is always better
  • Ignoring team/operational complexity
  • Refusing to revise when constraints change

knowledge checks

Start with these quick checks, then explain the closed-book questions in your own words.

  1. 01What makes a tradeoff answer complete?

    select an option to check your answer

  2. 02When challenged, first…

    select an option to check your answer

closed-book recall

Close the worked example and explain these from memory. Answers are self-reviewed. Drafts stay on this page; save anything you want to keep in chapter notes.

Rate the assignment and recall together

Use the assignment rubric as evidence. Completion is your own judgment; this score schedules practice.

interview drill

Complete ten 60-second tradeoff rounds. Record each and cut any answer that exceeds 90 seconds.

  • 10 rounds
  • 60 sec each
  • explicit choice
  • reversal trigger
compare a strong approach after your attempt

Use: ‘The deciding constraints are __. X gives __ but costs __; Y gives __ but costs __. I choose X because __. If __ changes, I would switch.’ Include SQL/NoSQL, SSE/WebSocket, sync/async, single/multi-region, and build/buy.

Compare decisions and failure behavior, then repeat with a changed constraint. Keep your own wording.

Use the timed mock workspace →

references

Sources offer deeper context. Provider capabilities and API contracts can change; check current official docs before implementing.

notes

saved locally