How to Approach a System Design Interview

The interview is not a box-drawing contest#

A strong candidate can turn an ambiguous prompt into a scoped design, explain why each major component exists, and adapt when a requirement changes. The boxes matter only because they make that reasoning visible.

Interviewers are watching how you handle ambiguity, identify scale, decompose a problem, find bottlenecks, reason about failure, and defend trade-offs. A polished diagram without those habits is a weak design.

1. Clarify the problem#

Ask enough questions to know what you are building. Identify the users, primary use cases, explicit exclusions, read/write shape, real-time expectations, geography, consistency, latency, availability, and cost constraints. You do not need to interrogate every possibility; you need the answers that change the design.

2. State assumptions, then estimate only useful scale#

Say your assumptions aloud: “Assume 100 million redirects and 10 million new URLs per day.” They need to be reasonable enough to test the design, not predictions accurate to three decimal places.

Estimate traffic, storage, bandwidth, and the read/write ratio only when the result can change a choice. The dedicated Capacity Estimation lesson shows the arithmetic.

3. Define the boundary, API, and core data#

A small interface forces precision about inputs, outputs, entities, and read/write paths. For the URL shortener, the boundary might begin as:

POST /urls
GET /{shortCode}

The first endpoint creates a mapping; the second resolves one. That immediately raises useful questions about duplicate requests, authorization for creation, and the latency of redirects.

ShortURL
--------
short_code
original_url
created_at
expires_at
user_id

Choose the model from the access patterns. The redirect path needs a lookup by short_code; that matters before a database brand does.

4. Draw the simplest viable architecture#

Client → Load balancer → URL service → Database

Start with the architecture that satisfies the requirements. Scale the part that actually needs scaling.

Do not add a cache, queue, shards, or replicas until the current design reveals a requirement or bottleneck that needs one. A simple baseline gives every later component a reason to exist.

5. Walk the critical flows#

Write path

The client submits a URL, the service validates it, assigns a short code, persists the mapping, and returns the result. Walking that path exposes duplicate submissions, uniqueness, and acknowledgement questions.

Read path

The redirect request reaches the service, loads the mapping, and returns a redirect. This reveals the high-volume database read and the user-visible latency path.

6. Find bottlenecks and choose depth#

For this prompt, redirect volume, database reads, hot links, ID generation, dataset growth, and regional latency are plausible pressure points. Improve the design in response: repeated reads may justify caching, growing ownership may justify partitioning, and global users may justify regional or edge delivery.

Interviewers normally prefer depth in a few consequential areas over shallow coverage of every tool. Follow the prompt toward cache strategy, partitioning, ID generation, consistency, failover, or another area that can break the design.

7. Discuss failures and trade-offs#

For each important component, ask what happens when it is slow, unavailable, or returning stale data. Consider a cache outage, database failover, crashed consumer, unavailable region, and timed-out dependency. Then describe both mitigation and remaining risk.

• Caching can lower latency, but introduces invalidation and stale-data behavior.
• Asynchronous work can shorten the request path, but moves correctness into retries, ordering, and eventual completion.
• Replication can improve availability, but introduces lag, failover behavior, and cost.
• Partitioning can increase capacity, but complicates cross-partition queries and rebalancing.

8. Close with a design summary#

Spend the last minute naming the requirements satisfied, expected scale, main decisions, largest trade-offs, and known limitations. The summary shows that the design is one coherent answer rather than a collection of boxes.