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.

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.

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?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Go deeper

Tech stacks

Skill areas

Suggest an improvement