Requirements and core entities

The first five minutes decide what the next forty are about. This lesson is about using them well.

Functional requirements: pick the core

Start by listing what users can do, phrased as "users can…". Then prioritize: in an interview, agree on the top three and explicitly park the rest.

For a URL shortener:

1. Users can create a short URL from a long URL (optionally with a custom alias or an expiry).
2. Users who visit a short URL are redirected to the long URL.
3. (Out of scope: analytics dashboards, user accounts, link editing.)

Writing "out of scope" is not laziness. It is a decision that lets you spend your time on the parts that matter.

Non-functional requirements: make them measurable

Non-functional requirements are where architecture comes from, so make them specific. Go through the usual list (scale, latency, availability, consistency, durability) and attach numbers and product reasons.

For the URL shortener:

• Scale: about 100 million new links per month; 100 redirects per link created.
• Latency: redirects under 100 ms at p99. People are waiting on a blank page.
• Availability over consistency for redirects: a redirect that works is more important than one that reflects a link created a second ago.
• Uniqueness: two long URLs must never get the same short code.
• Durability: a created link must never be lost.

Notice the two that pull against each other: high availability for reads, but strict uniqueness for writes. The design will treat reads and writes differently, and the requirements already told you so.

Read/write ratioread-heavy → caches, replicas

100:1

Latency targetkeep the read path short

p99 under 100 ms

Consistency needstrict for money and uniqueness, relaxed for feeds

per feature

Peak vs averagedesign for the peak

often 3–10×

Data growthdecides when you must shard

per year

Core entities: the nouns

Now list the main things the system stores and serves. Keep it to the nouns; fields come later when the design needs them.

For the URL shortener:

• Link: short code, long URL, created at, expires at, creator.
• User (only if accounts are in scope).

For a news feed you might list User, Post, Follow and Feed item. For a ticketing site, Event, Seat, Booking and Payment.

Entities give you and the interviewer a shared vocabulary. "The Booking references a Seat" is much clearer than "the thing that holds the reservation".

Quick check

Quick check

For a ride-sharing app, which list is the best set of core entities?

ARider, Driver, Ride, Location updateBPostgres, Redis, KafkaCRequest, Response, HeaderDMicroservice, Gateway, Pod

Try it

News Feed HLD

Practice listing requirements and entities for a read-heavy product with a write fan-out problem.