Architecture scenarioMedium~10 min

Interview question

You are asked to design a high-traffic ordering system, but the requirements are vague. How do you frame the problem before drawing the architecture?

Frame requirements and capacity before designing a system

Frames a vague system-design problem with explicit flows, constraints, scale estimates, and measurable quality targets before selecting components.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would begin with the main actors and flows: what users create or read, which action is business-critical, and what result must be immediate. Then I would clarify expected users, average and peak request rates, data size, retention, latency, availability, durability, security, and consistency needs. When exact numbers are unavailable, I would state reasonable assumptions and mark them as assumptions. I would finish the framing with a small API and data sketch so the first architecture targets the critical path rather than every possible feature.

Full answer below

Practice focus

Requirement discovery, assumptions, capacity estimates, SLOs, critical flows, data shape, constraints, and architecture prioritization.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Architecture choices only make sense against a workload and its constraints. A short framing pass prevents the discussion from becoming a list of technologies with no reason behind them.
I would begin with the main actors and flows: what users create or read, which action is business-critical, and what result must be immediate. Then I would clarify expected users, average and peak request rates, data size, retention, latency, availability, durability, security, and consistency needs. When exact numbers are unavailable, I would state reasonable assumptions and mark them as assumptions. I would finish the framing with a small API and data sketch so the first architecture targets the critical path rather than every possible feature.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would turn the largest assumptions into rough orders of magnitude. Peak writes, read-to-write ratio, payload size, daily storage growth, bandwidth, and burst shape reveal whether one database and a few application instances are enough or whether a queue, cache, partitioning, or asynchronous workflow earns its complexity. I would separate hard invariants, such as never charging twice, from softer goals, such as a feed updating within a few seconds. That distinction lets the design spend consistency and availability where the product actually needs them. I would also name what is outside the first version so the architecture remains focused.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
I would connect the estimates to measurable SLOs and an evolution plan. For example, I might target a p95 write latency, an availability objective for checkout, a recovery target, and a maximum acceptable backlog age for background work. I would identify the assumptions most likely to invalidate the design and propose a load test, production metric, or small prototype for each one. Capacity would include failure headroom and growth, not only the expected average. I would record the decisions and their triggers so the team knows when a replica, queue, new service, or data partition becomes justified instead of installing all of them on day one.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Starting with products or cloud services before clarifying the workload.
Using precise-looking estimates without stating their assumptions.
Treating every endpoint as if it has the same latency and availability needs.
Designing distant future scale while leaving the critical user flow vague.

Red flagsCandidateSigns the approach is fragileSignals that an interviewer may treat as risky.Open details

Details

No clear critical flow or source of truth emerges from the design.
Scale numbers never influence a component or trade-off.
Consistency, recovery, security, and cost constraints remain implicit.
There is no simpler first version or trigger for later complexity.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

Which estimate would most likely change your architecture?
How would you translate a product requirement into an SLO?
What would you deliberately leave out of the first version?

Continue practice

Move to the linked follow-up, next path step, prerequisite, or deeper variant.