Requirements: functional & non-functional

The first five minutes decide the interview. Rushing into architecture before pinning down what you're building is the #1 mistake. This lesson is the requirements-gathering step — how to turn "design a chat app" into a scoped, estimable problem.

Functional vs non-functional

• Functional — the features. "Post a tweet," "follow a user," "get the feed." These define the API.
• Non-functional — the qualities. Scale, latency, availability, consistency, durability. These define the architecture. This is where senior candidates separate themselves — they drive the design from the non-functional needs.

Questions to always ask

Never assume. Open with clarifying questions:

• Who & how many? "How many daily active users? Reads vs writes?"
• Scope? "Are we handling media, or just text? Group chats or 1-on-1?"
• What matters most? "Is this read-heavy or write-heavy? Is low latency or strong consistency more important?"
• What's out of scope? Explicitly park things: "I'll assume auth is handled; I'll focus on the messaging path."

The read/write ratio is everything

One number shapes the whole design: is the system read-heavy (Twitter feed: 100:1 reads) or write-heavy (analytics ingestion)? Read-heavy → cache and replicate aggressively. Write-heavy → focus on ingestion throughput, queues, and partitioning. Ask this early; it steers every later decision.

Nail down consistency vs availability

Does every user need to see the exact same data instantly (a bank balance → strong consistency), or is slightly-stale okay for uptime (a like count → eventual consistency)? This single choice (the CAP trade-off, section 3) cascades through your database and replication design.