What System Design Is and What You Must Explain

Requirements and the Design Framework · 30 min

System Design · Module 1 · Lesson 1 of 4 · 30 min

What System Design Is and What You Must Explain

Learn what a design answer contains, distinguish high-level from low-level design, and connect every box to a real request.

A useful design explains who requests what, where the authoritative state lives, and how the request can fail.

01 The idea

The problem this lesson solves

A reader requests /r/a7. The service must either return the stored destination or a documented missing result.

Start here with basic programming and arithmetic.

ComponentA unit with a responsibility and an interface, such as an API or a database.
HLDHigh-level design: components, data flow, scale and failure behavior.
LLDLow-level design: interfaces, classes, states and implementation decisions inside a component.

02 Worked example

Follow one worked example

What System Design Is and What You Must Explain worked diagram01ReaderGET /r/a702ApplicationValidate + route03DatabaseOwns mapping04ResponseRedirect or errorWhat System Design Is and What You Must Explain compact diagram01ReaderGET /r/a702ApplicationValidate + route03DatabaseOwns mapping04ResponseRedirect or error
Reader: GET /r/a7 • Application: Validate + route • Database: Owns mapping • Response: Redirect or error.

Trace the example in order. Follow the same identities, units and state transitions through the diagram and the events below.

1
Name the actionA reader requests /r/a7. The service must either return the stored destination or a documented missing result.
2
Assign ownershipThe app interprets HTTP; the database owns the durable code-to-destination mapping.
3
Trace successRead a7, obtain https://example.com/guide, and return a redirect with Location.
4
Trace failureA database timeout is not the same as an absent code. Return a retryable service error rather than an invented 404.

A useful design explains who requests what, where the authoritative state lives, and how the request can fail.

03 The method

Mechanisms decisions and a guided tutorial

Work through the explanation in order, then apply it in the tutorial. Each comparison names a cost as well as a benefit.

Choice or conceptPurposeBoundary or cost
ClientRequests a redirectDoes not decide whether a code exists
ApplicationValidates and respondsMust distinguish missing from unavailable
DatabasePersists mappingsNeeds a recovery and capacity plan

Clarify the kind of design

High-level design describes services, data stores, request paths and failure behavior. Low-level design describes classes, interfaces, state transitions and implementation details inside a component. ‘Design a parking lot’ can mean either. Ask what artifact is expected before choosing a level. The short-link service here is a high-level exercise: explain the components, request paths and durable mapping before specifying implementation classes.

Start with one user action

A student opens a short link. The product behavior is small: find the stored destination and send a redirect. Begin by naming the client, the request, the stored mapping and the response. You can now draw client → application → database without choosing a cloud provider.

Follow one code through the drawing. The client sends a7. The application looks up a7, receives its destination, and returns a redirect. The database is authoritative because the service must recover the same mapping after an application restart. Each arrow has a payload and each component has a reason to exist. This is already a design, even though it has only three boxes.

Decisions are more valuable than product names

Compare two explanations: “we use a distributed database” and “one database currently meets measured demand; we will add read capacity when query latency exceeds the target under the expected peak.” The second tells a reviewer how to evaluate the choice. A technology name is useful only after you state the behavior you need from it.

Ask four questions at each box: what does it receive, what does it return, what state does it own, and what happens when it times out? These questions expose missing contracts. An arrow labeled “data” hides whether the call is a lookup, a write, an event or a bulk transfer. Use an operation name and one sample payload instead.

Choose the expected artifact

For a single-process link encoder, low-level design might define a repository interface, a code generator and error handling. For the public service, high-level design adds authentication, deployment, storage ownership and failure boundaries. Both need good reasoning, but the deliverables differ.

Practice explaining a three-box design in ninety seconds. State its scope, trace one successful request and one missing-code request, then name its first limit. Do not add queues or shards merely to fill the drawing. Expand the model only when another requirement makes a new responsibility necessary.

Guided tutorial

1. Write the contract

Describe a successful redirect and a missing-code response in two sentences.

2. Draw three boxes

Label every arrow with the actual value or operation it carries.

3. Cross out a component

Remove the app, then the database, and describe the user-visible failure in each case.

4. Change the artifact

Now specify the classes you would implement for an in-process repository; identify what belongs to LLD.

client → GET /r/a7 → application
application → find_by_code("a7") → database
database → destination or missing → application
application → redirect or documented error → client

04 Cheat sheet

Review the decisions

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

Choice or conceptRememberCheck
ClientRequests a redirectDoes not decide whether a code exists
ApplicationValidates and respondsMust distinguish missing from unavailable
DatabasePersists mappingsNeeds a recovery and capacity plan
ComponentA unit with a responsibility and an interface, such as an API or a database.
HLDHigh-level design: components, data flow, scale and failure behavior.
LLDLow-level design: interfaces, classes, states and implementation decisions inside a component.

05 Where & why

Check the primary references

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

Primary reference
HTTP 429

Read HTTP 429

Primary reference
Redis atomic scripting

Read Redis atomic scripting

State the implementation version and the workload assumptions when defending your own design.

06 Interview questions

Explain the reasoning out loud

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

What does Component mean?
A unit with a responsibility and an interface, such as an API or a database.
What does HLD mean?
High-level design: components, data flow, scale and failure behavior.
What does LLD mean?
Low-level design: interfaces, classes, states and implementation decisions inside a component.
What makes a box-and-arrow drawing a design?
Its responsibilities and contracts explain how requirements are met. A successful request trace and a failure trace reveal whether the drawing is complete.
Why not choose the database first?
Data access, durability and scale requirements determine which database capabilities matter. Choosing a product first can make the design fit the product instead of the problem.
Can a small design be a good answer?
Yes, when it satisfies the stated requirements and honestly identifies its limits. Complexity should have a measurable reason.
What is the first failure to trace?
Choose a dependency needed by the main user action, such as the mapping store. State the timeout result and how the client can recover.
How do you choose the level of detail?
Confirm whether the requested output is a service architecture, an object model or working code. Keep the initial explanation at that level and deepen selected parts when needed.

07 Practice problems

Practice a new case

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

Identify responsibility

Easy
For a notes app, assign user input, authorization and durable note storage to appropriate components.
Follow-up
State the assumption or edge case that makes the answer correct.
Show the hint
Follow one save action.

Name the artifact

Easy
List the expected output for designing one elevator controller versus a service managing a fleet.
Follow-up
State the assumption or edge case that makes the answer correct.
Show the hint
Separate local state transitions from remote coordination.

Trace absence

Medium
Explain why a storage timeout must not automatically become a missing-note response.
Follow-up
State the assumption or edge case that makes the answer correct.
Show the hint
Absence is a data result; timeout is an unknown result.

Remove a box

Medium
Decide whether a cache is necessary for a service doing 3 inexpensive reads per second.
Follow-up
State the assumption or edge case that makes the answer correct.
Show the hint
Ask which requirement it improves.

Describe the arrows

Medium
Write the request and result on each arrow of a three-component image-metadata lookup.
Follow-up
State the assumption or edge case that makes the answer correct.
Show the hint
Use a concrete identifier.

Defend a minimal design

Hard
Design a campus announcement service for reading and posting messages, then explain its first two limits.
Follow-up
State the assumption or edge case that makes the answer correct.
Show the hint
Separate the posting permission from public reading.

Worked solutions

1. Identify responsibility

The client collects input; the API validates and authorizes; the database durably stores the note. The API must derive identity from authentication rather than trust an owner supplied by the client.

2. Name the artifact

One controller needs states, events and interfaces. A fleet service needs device identity, APIs, telemetry storage and behavior when devices disconnect.

3. Trace absence

A timeout does not prove absence. Return a documented unavailable response with a bounded retry policy; report missing only when an authoritative lookup succeeds and finds no accessible record.

4. Remove a box

The rate alone does not justify a cache. Measure latency and database capacity first; a cache introduces freshness, memory and recovery obligations.

5. Describe the arrows

The client sends image id p1 to the API; the API requests p1 metadata from the store; the store returns metadata or absence; the API returns the authorized representation or documented error.

6. Defend a minimal design

Use a client, an authenticated API and durable message storage. State ordering, retention and posting permissions. Initial limits might be database read capacity and one-instance availability; add complexity only when the targets require it.