The Five Step Design Framework

01 The idea

The problem this lesson solves

A design interview often fails before any difficult distributed-systems question appears: the candidate draws a cache, queue and database, but never establishes what the user can do or which data must stay correct. A framework prevents that drift. Here you will build a short-link service as a connected set of decisions, showing what each step produces and how the next step uses it.

You need basic programming and arithmetic. This module introduces the design vocabulary; the next module develops HTTP step by step.

02 Worked example

Build a short-link design in five steps

03 The method

Understand the mechanism

Step 1: turn the prompt into a bounded product

Start with “create and follow short links.” Creation takes a destination and returns a code. Following a code returns a redirect. Management operations require an authenticated owner. For this exercise, destinations may change; click analytics, billing and custom domains are excluded. This gives the design a specific freshness problem without introducing an analytics pipeline.

Now state correctness rules. Codes must be unique in their namespace. Only the owner can change a destination. A successful creation must survive an app restart. A missing code and an unavailable database must produce different outcomes. These rules become tests for the API and database rather than vague notes in a diagram.

Record service targets separately. Assume one region, a defined peak workload and a latency target measured at the gateway. If no workload is supplied, choose exercise inputs and label them. The objective is to make progress with visible assumptions, not to discover the company’s actual private traffic.

Your first artifact is a scope box containing actions, exclusions, workload and correctness rules. Keep it short enough to revisit. When the discussion later asks for instant global updates, you can point to the single-region assumption and explain what must change.

Step 2: estimate only quantities that can change the design

Use the course workload: 100,000 daily active users, ten redirects each day, 10,000 new links per day and a 5× read and write peak factor. Daily redirects are 1,000,000. Dividing by 86,400 gives about 11.57 average reads/s; multiplying by five gives about 57.87 peak reads/s. Peak creations are about 0.579/s.

At 500 modeled bytes per mapping and one year of retention, logical mapping data is 10,000×500×365 = 1.825 GB. This excludes indexes, replicas, transaction logs and backups. You are not claiming the complete database occupies 1.825 GB; you are establishing the scale of its logical records.

These numbers make some decisions easier. They do not by themselves justify sharding. A relational database with suitable queries is a candidate to benchmark. A cache may still be useful for a latency target or a viral link, but it should not be introduced because “every scalable system has Redis.”

The artifact is a worksheet with units and assumptions. Retain the separate read and write rates because they stress different paths. When a new requirement adds one analytics event per redirect, you can see that this creates far more writes than link creation did.

Step 3: define the API and the data together

Write three operations: POST /v1/links creates a mapping, GET /r/{code} follows it, and PATCH /v1/links/{code} changes a destination. The management API derives owner identity from authentication. Public redirect requests use the code as their lookup key.

A minimal mapping record contains code, owner_id, destination, created_at and a version or update timestamp. Code uniqueness belongs in a database constraint. An owner listing needs an index that begins with owner_id and supports its chosen ordering. These access patterns explain the keys before a storage product is chosen.

Creation retries need their own identity. A client can retry after the server commits but before the response arrives. Store an idempotency key scoped to the caller and operation, a request fingerprint, and the completed result within an appropriate transaction. A random new code on every retry would turn one user action into several links.

Specify failure responses with the same care as success. A malformed destination is a validation failure. A caller without permission is not a storage failure. A timed-out lookup is not proof that the code is missing. The artifact is an API table tied to schema operations and invariants.

Step 4: walk a minimal architecture

Begin with a client, an HTTP entry point, replaceable app instances and a durable mapping database. Creation reaches an app, authenticates the owner, validates the destination and commits the mapping with its replay record. The response identifies the saved resource. Redirect reaches an app, looks up the code and returns Location when the lookup succeeds.

Do not add a component until you can put it on a particular request path. If a cache is introduced, say exactly which reads consult it, how keys are formed, what is cacheable and how destination edits affect copies. If a queue is introduced for optional click analytics, the redirect’s success should not silently depend on completing the analytics work.

Draw responses and failures as well as requests. An arrow app → database means a network operation with a timeout and a finite connection budget. If the database slows down, each app may hold more in-flight requests and connections. Increasing app count can amplify that pressure instead of fixing it.

The artifact is a diagram another person can execute. They should be able to trace one creation and one redirect, name the authoritative state, and identify what happens if an app disappears after a commit.

Step 5: deepen the highest-risk decisions

Choose a deep dive by asking which mistake could invalidate the promised behavior. For this service, two useful candidates are retry-safe creation and mutable-destination caching. For seat booking, concurrency would be the priority. For large video delivery, bandwidth and placement would likely dominate.

Work one race all the way through. Reader R misses the cache and reads destination v1. Writer W commits v2 and deletes the cached key. R then fills the cache with v1. A delete-after-write policy alone has not guaranteed immediate freshness. The design must accept a defined stale window or add stronger coordination, version checking or a bypass for strict reads.

Then examine an outage. If the cache starts empty, database demand returns to the uncached rate. If an app is removed, survivors need enough tested capacity. If creation times out, a repeated idempotency key should recover the recorded outcome. These cases test the interactions between components rather than each component in isolation.

The artifact is a failure table: trigger, user-visible result, recovery owner and verification signal. “We retry” is insufficient without a deadline, eligible error set and guarantee that repeated attempts do not duplicate the effect.

Present the reasoning and know when to stop

A useful explanation follows the dependencies of the decisions. State the requirements, show the sizing assumptions, define the operations and data, trace the architecture, and then examine the risky behavior. This lets the reviewer challenge an assumption without losing the whole thread.

For a 45-minute practice session, one possible allocation is 5 minutes for scope, 5 for estimates, 8 for API/data, 12 for the architecture and 15 for failure analysis and review. This is a practice allocation, not a universal interview rule. Its purpose is to reserve real time for correctness rather than spending the entire session drawing boxes.

End with explicit trade-offs. A single authoritative database makes some invariants easier but remains a capacity and availability concern. A cache reduces repeated reads but creates a freshness obligation. Delaying sharding reduces operational complexity but requires measurable thresholds for revisiting the choice.

A design is ready for review when every important requirement has a mechanism and every mechanism has a stated limit. It need not anticipate every future feature. It must explain what it delivers now and which changed assumptions would justify a different design.

1 clarify → scope + correctness rules
2 estimate → traffic + storage + likely bottleneck
3 data/API → operations + keys + error contracts
4 architecture → ownership + request paths
5 deep dive → races + failures + trade-offs

04 Cheat sheet

Review the decisions

Use this table to explain the mechanism and its limit without memorizing a product name.

05 Where & why

Check the primary references

Use official references for protocol and implementation details. The questions here are teaching prompts.

06 Interview questions

Explain the reasoning out loud

Answer before opening the explanation. The questions progress from vocabulary to decisions and failure behavior.

07 Practice problems

Practice a new case

Solve the new cases before revealing hints. Complete worked solutions follow the set.

Worked solutions