Gyaan

Requirements Gathering

beginner 0-2 YOE system-design requirements functional non-functional scalability

Every system design problem starts with the same question: what exactly are we building? The interviewer gives us a vague prompt like “Design a URL shortener” — it’s our job to turn that into a clear list of requirements before drawing a single box.

Two Types of Requirements

Functional vs Non-Functional Requirements
Functional (WHAT)
What the system does
─────────────────
• Shorten a long URL
• Redirect short URL to original
• Custom short links
• Analytics / click tracking
• Link expiration
Non-Functional (HOW WELL)
How well the system does it
─────────────────
• Low latency (<100ms redirect)
• High availability (99.9%)
• Scalable (billions of URLs)
• Durable (links don't disappear)
• Eventual consistency is OK

Functional requirements describe features — what the user can do. Non-functional requirements describe quality — how well it works under the hood.

Key Non-Functional Requirements

These come up in almost every system design interview. We need to know them cold:

Scalability — Can the system handle growth? From 1,000 to 1,000,000 users without a rewrite.

Availability — Is the system up when users need it? Measured in “nines” — 99.9% means ~8.7 hours of downtime per year, 99.99% means ~52 minutes.

Consistency — Does every user see the same data at the same time? Strong consistency means yes. Eventual consistency means “give it a second.”

Latency — How fast does the system respond? A search engine needs <200ms. A batch report can take minutes.

Durability — Once we store data, does it stay stored? We can never lose a user’s photo or a bank transaction.

How to Ask the Right Questions

Don’t just sit there and guess. Ask questions like:

  • “How many users are we designing for?”
  • “What’s the read-to-write ratio?”
  • “Do we need real-time or is a few seconds of delay OK?”
  • “What’s more important — consistency or availability?”
  • “Should we handle this feature, or can we scope it out?”

The interviewer expects us to ask. Not asking is a red flag.

Example: URL Shortener Requirements

Let’s say the interviewer says “Design a URL shortener like bit.ly.” Here’s how we’d gather requirements:

Questions we’d ask:

  • How many URLs shortened per day? → “100 million”
  • Read-heavy or write-heavy? → “100:1 read-to-write ratio”
  • Do short URLs expire? → “Optional, default no expiry”
  • Custom short URLs? → “Nice to have, not core”
  • Analytics? → “Not in scope for now”

Functional requirements (after discussion):

  1. Given a long URL, generate a short URL
  2. Given a short URL, redirect to the original
  3. Short URLs should be as short as possible

Non-functional requirements:

  1. Very low latency for redirects (<100ms)
  2. High availability — links must always work
  3. Shortened URLs should not be predictable (security)

Now we have a clear scope. We know what to build and what quality bar to hit. Everything after this — estimation, design, deep dives — flows from these requirements.

The Trade-Off Question

Here’s a pro tip: non-functional requirements often conflict with each other. We can’t have perfect consistency AND perfect availability (that’s the CAP theorem, which we’ll cover later). When we state our requirements, we should also state which one wins when they clash.

For a URL shortener: “Availability is more important than consistency. If a link takes a few seconds to propagate globally, that’s fine. But a link should never be down.”

In simple language, requirements gathering is about turning a vague question into a concrete plan. It takes 5 minutes in an interview but sets the direction for everything that follows. Skip it, and we’re building blind.

References