Explain a design through its tradeoffs
Picture
Who accepts it, who validates it, where does it commit, and what confirms success? A missing answer often reveals an unclear ownership boundary.
Predict
Does drawing more services by itself make a design stronger?
Walk through the small example
No, explain the guarantees and tradeoffs. Each box should earn its place through a requirement or measured constraint.
Mental model and runnable Python model
Use a repeatable review: requirements and estimates; API and data model; one write and one read; bottleneck and scale plan; consistency and ownership; failures and retries; security and observability; alternatives and what would change your choice. Connect LLD and HLD deliberately: an in-process Strategy swaps policy, while a service boundary adds network failure; a local lock protects shared memory, while a database transaction coordinates shared stored state. The names are clues, not substitutes for a contract.
What the function promises: The model checks whether a written design outline includes the core review areas. It cannot judge the quality or correctness of the reasoning.
REVIEW_AREAS = (
"requirements", "api", "data", "write_path", "read_path",
"failure", "consistency", "security", "observability", "tradeoff"
)
def missing_design_areas(outline):
return [area for area in REVIEW_AREAS if not outline.get(area)]
outline = {area: "Reasoned explanation goes here" for area in REVIEW_AREAS}
assert missing_design_areas(outline) == []
del outline["failure"]
assert missing_design_areas(outline) == ["failure"]Work and storage: O(number of review areas). Passing a checklist is not proof that the design is correct.
When to recognize it: Ask what a retry does after the first attempt may already have succeeded. This exposes missing identity and transaction rules.
Check before applying it: A checklist supports reasoning; it does not certify a design or replace evidence about its workload.
Change one rule
The interviewer cuts expected traffic by a thousand and removes independent deployment requirements. What should you reconsider?
See what changes
Remove unjustified machinery. A simpler modular application and one suitable database may now satisfy the same user promises with fewer operational failure modes.
Connect
Design a URL shortener: Practice tracing a complete write and read on a small concrete system.
recognition: Use guarantees and counterexamples rather than recognizing names alone.