---
title: "How to clarify requirements in system design"
description: "Turn 'design a URL shortener' into a brief: roles, operations, invariants, freshness, what must finish now, and the scale and retention numbers to settle."
canonical_url: "https://fanout.sh/system/archive/requirements-clarification"
md_url: "https://fanout.sh/system/archive/requirements-clarification.md"
access: "public"
---

# How to clarify requirements in system design

Turn 'design a URL shortener' into a brief: roles, operations, invariants, freshness, what must finish now, and the scale and retention numbers to settle.

## Public overview

Requirements clarification

Requirements clarification turns a broad request into a design problem you can reason about. Before choosing a database or drawing services, establish who uses the system, what they need to accomplish, and which promises must survive load and failures.

We will turn “design a URL shortener” into a small brief. The same questions apply to a feed, file store, or payment service; the answers will change.

Start with the people and the operation

A link creator submits a destination and receives a short address. A reader opens that address and expects to reach the destination. An administrator may need to disable an abusive link. These are three roles with different permissions, even if one person sometimes fills all three.

Now follow the main operation. Can the creator choose the short name? Can its destination change? Must readers sign in? Each answer changes something the implementation must enforce.

For this course's shortener, assume approved callers can create links, names are generated, destinations stay fixed, and anyone can follow a link. Custom aliases and destination editing are outside the first version. Abuse handling still needs an owner; leaving out editing does not make unsafe destinations harmless.

Write these choices down as assumptions to confirm with the product owner. A plausible answer becomes a requirement only when the people responsible for the product agree to it.

Ask what must remain true

A generated name must not silently replace somebody else's mapping. A saved link must keep its destination through the promised retention period. These are invariants : conditions the implementation must preserve, including when requests overlap or are retried.

Also identify the authoritative data. The stored mapping decides where a link goes. A cached copy can speed up reading it, but does not become a separate authority that may choose a different destination.

Freshness needs its own question. If an administrator disables a link, how long may a cached copy still redirect readers? An acceptable delay of a minute permits different choices from a requirement to stop every new redirect immediately. Do not leave that promise hidden inside “we will cache it.”

Separate work that must finish now from work that can wait

“Record clicks” is ambiguous. Our server can record a redirect request; it cannot infer a distinct person or prove that the destination page loaded.

The shortener exercise requires each accepted redirect request to have a stored event before the response. Reports may be calculated later. If storing the event fails, this version returns an error. That is a deliberate product tradeoff: event retention takes priority over redirect availability during that failure.

Another product could choose to redirect anyway and tolerate missing events. The important question is which promise the design is supposed to keep. Moving report calculation into the background does not answer whether losing its input is acceptable.

---
This representation contains public Fanout content only. Protected Pro lessons, account data, billing, checkout, and pricing are not included.

Browse the public content map: https://fanout.sh/sitemap.md