How to gather and clarify system design requirements
functional requirements, non-functional requirements, read/write ratio, DAU estimation, SLA definition, scope bounding
Requirements Clarification
Every strong system design answer starts with the same two questions: what must the system do, and how well must it do it?
Functional Requirements
These define behavior โ the features users interact with. For a messaging app:
- Users can send and receive messages
- Messages are delivered in order
- Users can see read receipts
Keep it to 3โ5 core flows. You can't design everything in 45 minutes.
Non-Functional Requirements
These define constraints the system must operate within:
- Latency: p99 read latency under 100ms
- Availability: 99.99% uptime (four nines)
- Consistency: eventual vs strong
- Scale: 10M DAU, 1B messages/day
Questions to Ask Every Time
Ask: How many daily active users? Read-heavy or write-heavy? Global or regional? What's acceptable downtime? What's the data retention policy?
These answers eliminate entire classes of architectural choices. A read-heavy system with eventual consistency needs completely different infrastructure than a write-heavy system requiring strong consistency.