Free lesson · System Design Interviews

Step 1: Functional and Non-Functional Requirements

Hard8 min readsystem-designinterview-prep

This is the question I recommend every candidate practice first. Not because it's the most interesting system design problem - it's not. But because it's the most commonly asked, it's small enough to cover end-to-end in 45 minutes, and it teaches the exact pacing and structure you need for harder questions. If you can nail URL Shortener in a mock interview, you've internalized the framework. Everything else is applying that framework to bigger systems.

I've asked this question over 40 times as an interviewer. Here's what I've learned: candidates who spend the first 5 minutes on requirements almost always deliver a stronger design than candidates who jump straight to drawing boxes. The requirements phase does two things - it narrows the problem to something you can actually design in 45 minutes, and it surfaces the constraints that drive every architecture decision you'll make later.

Let me show you exactly how to run this conversation with the interviewer.

What a URL Shortener Actually Does

Before we get into requirements, let's make sure we're on the same page about what we're designing.

A URL shortener takes a long URL like https://www.example.com/products/electronics/wireless-headphones?ref=summer-sale&utm_source=newsletter and converts it into a short one like https://short.ly/a3Xb9k. When a user visits the short URL, the system redirects them to the original long URL.

flowchart LR
    USER["User"] -->|"Visits https://short.ly/a3Xb9k"| SYSTEM["URL Shortener<br/>Service"]
    SYSTEM -->|"301 Redirect to<br/>original long URL"| DEST["Destination<br/>Website"]
    
    CREATOR["Link Creator"] -->|"Submits long URL"| SYSTEM
    SYSTEM -->|"Returns short URL:<br/>https://short.ly/a3Xb9k"| CREATOR

A URL shortener has two operations. First, a link creator submits a long URL and receives a short URL back. Second, when any user visits the short URL, the system looks up the original long URL and redirects the user's browser to the destination website. These are the two core flows: creation and redirection.

Simple, right? But the design decisions hiding inside this simple description are what make it an excellent interview question. How do you generate the short code? How do you handle billions of redirects per day? How do you store the mappings efficiently? How do you handle expiration? What about custom short URLs? Analytics? The question is a Trojan horse - it looks small but opens up into real distributed systems thinking.

The Requirements Conversation

Here's how to structure the requirements conversation. You ask questions, the interviewer answers (or tells you to make assumptions), and you write down the scope explicitly.

Functional Requirements - What the System Does

These are the questions to ask and the typical answers you'll get:

Q: "What are the core features?"

The two non-negotiable features are URL shortening (long → short) and URL redirection (short → long). Everything else is a follow-up.

Q: "Should users be able to choose custom short URLs?"

This is a crucial question because it changes the design. If yes, you need a uniqueness check against user-supplied strings. If no, you only need to generate random strings and check for collisions. Most interviewers say yes - it's a more interesting design problem.

Q: "Do short URLs expire?"

If yes, you need a TTL mechanism - either a default expiration (e.g., 5 years) or user-configurable expiration. If no, every URL lives forever, which means your storage grows monotonically. Most interviewers say yes with a default expiration.

Q: "Do we need analytics? Click counts, geographic data, referrer tracking?"

This determines whether you need an analytics pipeline alongside the core redirect flow. Most interviewers say "basic analytics - click count is fine, geographic breakdown is a bonus."

Q: "Do users need accounts, or is this anonymous?"

If accounts exist, users can manage their URLs (edit, delete, view analytics). If anonymous, anyone can create a short URL with no management capabilities. This affects the API design and database schema.

The Functional Requirements Summary

After the conversation, state your scope explicitly:

Important: Functional Requirements (confirmed with interviewer):

1. URL Shortening: Given a long URL, generate a unique short URL
2. URL Redirection: Given a short URL, redirect to the original long URL
3. Custom Short URLs: Users can optionally specify a custom short code (e.g., short.ly/my-brand)
4. URL Expiration: Short URLs expire after a configurable TTL (default: 5 years)
5. Basic Analytics: Track click count per URL

Out of Scope (explicitly deferred):

• User accounts and authentication
• Detailed analytics (geographic, referrer, device breakdown)
• QR code generation
• Link editing after creation
• Bulk URL creation API

The "out of scope" list is just as important as the "in scope" list. It tells the interviewer you understand the full problem space but are deliberately narrowing for the time available. This is a senior signal.

Non-Functional Requirements - How the System Performs

Non-functional requirements drive your architecture decisions more than functional requirements do. "We need URL shortening" tells you what to build. "We need to handle 100,000 redirects per second with <50ms latency" tells you how to build it.

Scale

Q: "How many URLs are created per day?"

This determines write throughput. A reasonable assumption: 100 million new URLs per day (roughly the scale of Bitly + TinyURL combined).

Q: "What's the read-to-write ratio?"

URL shorteners are extremely read-heavy. Each URL is created once but clicked many times. A typical ratio is 100:1 or even 1000:1. Let's assume 100:1.

This means:

• Writes: 100 million/day → ~1,200/sec average, ~3,600/sec peak
• Reads (redirects): 10 billion/day → ~120,000/sec average, ~360,000/sec peak

flowchart LR
    subgraph WRITES["Write Path (1,200 QPS avg)"]
        W["Create short URL"]
    end
    
    subgraph READS["Read Path (120,000 QPS avg)"]
        R["Redirect (100x more frequent)"]
    end
    
    WRITES ---|"100:1 ratio"| READS
    
    NOTE["Read-heavy workload →<br/>Caching is critical for the read path.<br/>The write path is not the bottleneck."]

The URL shortener has a 100-to-1 read-to-write ratio. Write QPS is about 1,200 average, peaking at 3,600. Read QPS for redirects is about 120,000 average, peaking at 360,000. This extreme read-heaviness means the architecture must optimize for fast redirects - caching is critical. The write path is comparatively low-traffic and not the bottleneck.

Latency

Q: "What's the latency requirement for redirects?"

Redirects must be fast. Every millisecond of redirect latency is a millisecond the user waits before seeing the destination page. Target: <50ms for redirects at p99.

URL creation can be slightly slower - users creating links tolerate a few hundred milliseconds. Target: <200ms for URL creation at p99.

Availability

Q: "What's more important - consistency or availability?"

For a URL shortener, availability wins. If a newly created URL takes 2 seconds to propagate globally, that's acceptable - the creator can retry. But if the redirect service is down, every short link on the internet breaks. Target: 99.99% availability for the redirect path.

Durability

Q: "Can we lose URL mappings?"

No. Once a URL mapping is created, losing it means every link pointing to that short URL is permanently broken. This isn't like a cache where you can regenerate the data - the mapping is the data. Target: Zero data loss for URL mappings.

The Non-Functional Requirements Summary

Important: Non-Functional Requirements:

Requirement	Target	Implication
Write throughput	~1,200 QPS avg, ~3,600 peak	Moderate - single database can handle this
Read throughput	~120,000 QPS avg, ~360,000 peak	High - needs aggressive caching
Redirect latency	<50ms p99	Cache-first architecture for reads
Creation latency	<200ms p99	Acceptable - write path isn't latency-critical
Availability	99.99% for redirects	Redundancy at every layer
Durability	Zero data loss for mappings	Replicated database with backups
Storage	5 years retention, ~100M URLs/day	~182 TB over 5 years (see estimation)

How Requirements Drive Architecture

The requirements you just gathered already tell you 80% of your architecture:

Interview: What the interviewer is evaluating: Did you ask the right questions? Did you distinguish between functional and non-functional? Did you explicitly scope what's in and what's out? Did you identify that this is a read-heavy system? Did you notice that availability matters more than consistency for this use case? The requirements phase is not a formality - it's the foundation that makes your entire design coherent.

Common Mistakes in the Requirements Phase

Key Takeaways

1. Spend 5 minutes on requirements - it's the highest-ROI step. Every minute spent here saves you from designing the wrong system. Candidates who skip requirements almost always end up backtracking.

2. Separate functional from non-functional requirements. Functional requirements tell you what to build. Non-functional requirements tell you how to build it. The architecture is driven by the non-functional requirements.

3. Identify the read-write ratio early - it shapes everything. A 100:1 read-heavy system needs aggressive caching. A write-heavy system needs write optimization. The ratio determines your architecture.

4. Explicitly state what's in scope and out of scope. This shows the interviewer you understand the full problem space and are making a deliberate choice to focus. Saying "I'm deferring analytics to keep the design focused" is a strength, not a weakness.

5. Availability > consistency for URL shorteners. A 2-second propagation delay for new URLs is tolerable. The redirect service being down breaks every short link on the internet. Design for availability first.

6. Requirements drive architecture decisions directly. Every non-functional requirement maps to a specific architecture choice. If you can draw that mapping explicitly, you've demonstrated senior-level thinking.

Exercise: Exercise 1: Run the requirements conversation for "Design Pastebin" - a system where users paste text and get a shareable URL. What functional requirements differ from URL Shortener? (Hint: content storage, content size limits, syntax highlighting, expiration models.) What non-functional requirements change? (Hint: content is larger than a URL mapping - how does that affect storage and caching?)

Exercise 2: For the URL Shortener requirements above, what happens if the interviewer says "We also need detailed analytics - click count by country, by device, by hour"? How does this change your architecture? Does it affect the redirect latency requirement? (Hint: analytics writes should be asynchronous - don't let them slow down the redirect path.)

Exercise 3: Run the requirements conversation for a URL Shortener that serves only enterprise customers (B2B SaaS). How do the requirements change? Think about: multi-tenancy, branded domains (links.company.com), access control (private links), compliance (data residency), and SLA guarantees. Write out the functional and non-functional requirements and compare them to the consumer version above.

Back to System Design Interviews