Requirements Gathering
Before designing anything, clarify functional requirements (what the system does), non-functional requirements (scale, latency, availability, consistency), and constraints (technology, team, budget).
Requirements gathering = asking the waiter questions before ordering. 'How spicy is it? Is it gluten-free? How big is the portion?' Skip this and you'll design a feast for 1,000 when they wanted a sandwich for 10.
Functional requirements: core features to support, user actions, data to store and query. Non-functional requirements: scale (DAU, QPS, data volume), latency targets (p99 < 200ms), availability SLO (99.9% vs 99.99%), consistency needs (strong vs eventual), geographic distribution (single region vs multi-region). Constraints: read/write ratio (read-heavy systems design differently than write-heavy), data size per entity, retention period. Always clarify before designing — the 'right' answer depends entirely on the requirements.
Experienced interviewers listen for what you ask as much as what you design. Asking 'What's the read/write ratio?' signals you understand that read-heavy systems (more replicas, caching) differ from write-heavy (sharding, write-optimized stores). Asking 'What's the consistency requirement?' shows you know the CAP trade-off. Red flags in requirements gathering: assuming the interviewer wants the most complex design, asking about specific technologies before understanding the problem, not asking about scale at all. Structure your questions: start with functional ('What are the core user actions?'), then scale ('How many users, how many requests per second?'), then constraints ('Any existing infrastructure or technology preferences?'), then non-functional ('What's the acceptable latency? What's the availability target?').
I always spend the first 5 minutes on requirements. My standard questions: (1) What are the core user-facing features in scope? (2) What's the expected scale — DAU, peak QPS for reads and writes? (3) What's the consistency requirement — can users see slightly stale data? (4) What are the latency targets? (5) What's the availability SLO? (6) Any geographic constraints (single region vs global)? Then I summarize what I heard and confirm before moving to design. This prevents designing a globally distributed real-time system when the interviewer wanted a simple CRUD app.
Spending too long on requirements gathering and not enough time on design. Allocate 5 minutes maximum, get the key answers, and design. You can revisit assumptions as you go. Interviewers want to see architectural thinking, not a requirements document.