Why this matters
Defining system requirements sets the foundation for all design decisions. Clear requirements ensure alignment between the system’s purpose and its implementation.
Functional Requirements
Start with customer needs and work backward to system functions.
The interviewer acts as a product owner.
Convert use cases into specific APIs.
Non-Functional Requirements
Use these as tiebreakers when comparing design options.
Common non-functional requirements include:
- Latency
- Throughput
- Availability
- Scalability
- Fault tolerance
- Data consistency
- Security
- Cost
Requirement Prioritization
Only implement features and mechanisms if explicitly requested.
Do not over-engineer.
No need to scale to millions of users unless specified.
No need to minimize latency if not requested.
No need to include full fault tolerance mechanisms.
Most systems will never reach YouTube, Facebook, or Twitter scale.
Cost and Trade-offs
Every design choice has a cost.
There are no universal guidelines for balancing requirements.
Validate assumptions with the interviewer.
Questions
- How do you convert a use case into an API?
- What are the most critical non-functional requirements for a small-scale system?
- Why is it important to validate assumptions with the interviewer?
- When should you introduce fault tolerance in a system?
- How do you determine if a system needs scalability?
- What trade-offs exist between latency and throughput?
- How does cost influence system design decisions?
- Can you list three examples of over-engineering in system design?
Key takeaways
- Start with customer needs to define functional requirements.
- Convert use cases into APIs.
- Use non-functional requirements to tiebreak design options.
- Only implement features if explicitly requested.
- Avoid over-engineering.
- Validate assumptions with the interviewer.
- Every design choice has a cost.
- Most real-world systems do not scale to social media levels.