Requirements

Every system design interview starts with ambiguity. The candidates who stand out are the ones who ask the right questions before touching the whiteboard.

Functional requirements

What the system must do — the core features. These directly shape your data model and API design.

• ›Users can post and read messages
• ›System supports file uploads up to 100MB
• ›Users can follow other users and see a feed
• ›API returns results within 200ms p99

Non-functional requirements

Quality attributes the system must have regardless of features. These drive your architectural decisions.

• ›Availability — 99.99% uptime means ~52 minutes downtime per year
• ›Consistency — do all users see the same data at the same time?
• ›Latency — what is the acceptable response time for reads vs writes?
• ›Durability — once written, data must never be lost
• ›Scalability — can the system grow to 10x, 100x traffic without rearchitecting?

What to ask the interviewer

Don't guess. Ask. These questions demonstrate seniority.

• ›How many users? Daily active users vs total registered?
• ›Read-heavy or write-heavy workload?
• ›Is strong consistency required or is eventual consistency acceptable?
• ›What is the expected data size — per record, per day, total?
• ›Any geographic distribution or latency SLAs?
• ›What failure scenarios matter most?

Interview tips

• ✓Spend 3–5 minutes on requirements before drawing anything
• ✓Write requirements on the board so the interviewer can correct you
• ✓Explicitly state your assumptions — don't leave them implicit
• ✓Prioritize: which requirement would you sacrifice first under pressure?

Follow-up questions to expect

• ?What happens if we need to support 10x more users?
• ?How would your design change if strong consistency was required?
• ?What's the most critical non-functional requirement to get right first?