How do you clarify system-design requirements?

Direct answer

What a strong answer covers

How it works

The first ten minutes of a design decide whether the rest is useful. Ask who the users are and what the two or three core flows look like; then quantify: daily active users, requests per second at peak, data volume and growth, read-to-write ratio, latency targets per flow, availability target, and how stale data may be. Add the constraints that shape architecture: consistency needs per operation, security and compliance, data retention, geography, and budget. Write the numbers down and use them to justify every component; features that do not affect the architecture are parked.

Example

For a chat product the questions that matter are group size, message retention, whether delivery order must be strict, and read fan-out at peak; the answers determine whether a single Postgres cluster suffices or whether messages need a partitioned log. A candidate who asks those before drawing boxes ends up with a design that fits the numbers instead of a generic microservices diagram.

Common mistakes

• Drawing components before knowing the peak load or the consistency requirement.
• Treating every feature as a core flow and never getting to the hard part.
• Guessing numbers silently instead of stating assumptions out loud.

A useful answer structure

Answer from your own work.

Do not memorise a script: use only examples you can explain honestly in follow-up questions.