System Design Interview: Make the Assumptions and Tradeoffs Visible

Practice requirements, capacity arithmetic, data contracts and failure reasoning through a hypothetical URL shortener. Separate an interview sketch from production...

An interview design is an argument, not a deployment plan

A useful system design discussion makes its assumptions inspectable. The interviewer should be able to change a requirement and see how your design changes with it.

You do not need to produce the largest possible architecture. You need to explain what the system must do, which constraints matter, why a design meets them and what remains unproven. Interview formats and evaluation criteria vary, so this guide is a practice method rather than a promise of interview success.

The example is a hypothetical URL shortener. It is deliberately incomplete as a production specification. Security review, measured capacity, operating procedures and deployment evidence would still be required.

Agree on the user journey before estimating capacity

Ask whether the service supports public redirects, authenticated link creation, custom aliases, expiration, editing and analytics. A public link and a private access-controlled link have different security and caching requirements.

For this exercise, assume authenticated users create links, anyone with an active code can follow a public redirect, and link owners can disable their links. Analytics are best-effort and must not block a redirect. Rich previews and fetching the destination content are out of scope.

Record the quality requirements in a form you can revisit:

| Requirement | Question to resolve | Consequence for the design | | --- | --- | --- | | Redirect delay | Where is latency measured, and for which request population? | Determines which work belongs on the synchronous path | | Link creation | Must a newly created link work immediately? | Constrains read routing and replication lag | | Disable behavior | How quickly must a disabled link stop redirecting? | Constrains server, browser and intermediary caching | | Durability | Which acknowledged records must survive a failure? | Determines persistence and recovery requirements | | Abuse handling | Who can create links and report harmful destinations? | Requires authorization and an operational response |

An availability objective is not the same as a contractual SLA. Google's SLO guidance explains defining indicators and objectives around user experience. State the measurement window and eligible events rather than selecting a number because it sounds impressive.

Estimate traffic with units that match the inputs

Daily active users are not simultaneous users. An estimate based on actions per day must be divided by seconds per day, not seconds per minute.

The following numbers are invented for practice, not market data or a capacity claim:

Daily active users:                   1,000,000 users/day
Redirects per active user per day:    20 redirects/user
New links per active user per day:    0.1 links/user
Seconds per day:                      86,400

Redirects/day = 1,000,000 × 20 = 20,000,000
Average redirect rate = 20,000,000 / 86,400 = 231.48/second

New links/day = 1,000,000 × 0.1 = 100,000
Average creation rate = 100,000 / 86,400 = 1.157/second

Assumed peak factor for this exercise: 6
Peak redirect estimate = 231.48 × 6 = about 1,389/second
Peak creation estimate = 1.157 × 6 = about 6.94/second

The peak factor needs traffic evidence in a real system. A single popular link can also create a hot key even if the total request rate is modest. Clarify whether the two peaks occur together and whether geographic distribution changes either estimate.

For a storage exercise, assume 500 bytes of logical data per new link and a full 365-day retention period with no deletions. Then 100,000 × 365 × 500 equals 18,250,000,000 bytes, or 18.25 decimal GB. That excludes indexes, replicas, backups, logs, analytics and storage-engine overhead. It is a lower-level input to sizing, not the required disk capacity.

Keep a small assumptions ledger so the interviewer can challenge one value without forcing you to restart the entire design.

Draw the simplest design that meets those assumptions

Use a durable mapping from code to destination, owner and state. The creation API validates the request and commits the mapping before acknowledging success. The redirect handler resolves an active code and returns an HTTP redirect. RFC 9110 defines the semantics of a 302 response; cache behavior must still be deliberately specified.

The diagram shows logical responsibilities rather than a deployment topology. The creation API and redirect handler may live in one application.

"type": "architecture", "title": "URL shortener: keep the redirect path explicit", "nodes": [ ], "links": [ ], "caption": "Arrows show requests or submitted events; responses are omitted. Analytics loss is an explicit exercise assumption. Stronger reporting requirements would need durable event delivery and reconciliation." }} />

Explain code generation and collision handling. A short code is an identifier, not an authorization mechanism. Validate allowed destination schemes, protect creation from abuse and define disabled or missing-code behavior. Do not add destination fetching without considering the additional security boundary.

Choose a datastore from the operations and correctness requirements. This example needs unique code lookup, durable creation and controlled state changes. A database brand does not follow automatically from a daily-user band.

Add caching only with a stale-data decision

First ask what evidence suggests the mapping lookup is the constraint. A cache may reduce repeated reads, but it adds another representation that can lag behind the source.

Microsoft's cache-aside guidance describes the miss-and-fill path and its consistency considerations. For this exercise, a missed code is read from the authoritative store, then optionally cached. A disabled link exposes the important question: how does a cached mapping stop being served within the agreed window?

Describe invalidation, expiration, concurrent fills and the behavior when invalidation fails. Decide whether the system can safely serve an old mapping. A cache outage should not create an uncontrolled surge of database requests; the fallback needs a tested capacity bound.

Do not infer strong consistency from the label “write-through.” The guarantee depends on the write acknowledgement, read path, concurrent writers and failure handling. If the interview requires immediate disable enforcement, explain the authoritative check or coordination needed instead of promising that a cache pattern supplies it automatically.

Scale the measured constraint, not every box

Horizontal scaling adds instances, but it does not remove shared limits. Database write capacity, connection pools, hot keys, quotas and coordination can still bound the system. Moving state out of application memory can simplify replacement, but stateful systems can also scale horizontally with appropriate partitioning and replication.

Read replicas introduce a freshness question. Sharding introduces routing, movement and cross-partition work. Microservices introduce network and operational boundaries. Explain which observed constraint would justify each change.

A small prototype or load test in production design would need representative key popularity, payloads, cache misses and dependency behavior. The back-of-envelope request estimate alone does not prove that a particular instance or database can support the workload.

Use failure questions to test the design

| Failure or changed requirement | What a credible answer should address | | --- | --- | | Creation succeeds but the response is lost | Safe request retry and how the caller finds the existing result | | A popular link overwhelms one key or partition | Hot-key behavior and bounded protection for the datastore | | A newly created record is absent on a replica | Read-your-write requirement and routing | | Cache invalidation fails after disabling a link | Permitted staleness and an authoritative enforcement path | | Analytics becomes mandatory for billing | Durable events, duplicates and reconciliation, not best-effort loss | | A new application revision misreads stored data | Compatibility testing and a rollback or repair path |

Discuss detection as well as mitigation. A process being alive is not evidence that a redirect works. Measure the relevant journey and distinguish missing telemetry from healthy service.

For a rollout, use compatible schema changes and a bounded traffic cohort. Restore the previous code only if it can read the current records and contracts. A code rollback does not undo data already written. Explain how partially completed work will be identified and repaired.

End the discussion with the remaining uncertainty

Summarize the selected design, the most important rejected alternative and the assumption most likely to change the decision. State what you would test next. This is more useful than adding another technology in the final minutes.

Practice review
  Requirements confirmed:
  Assumptions introduced:
  Arithmetic checked, including units:
  Authoritative data and consistency contract:
  Critical request path:
  First likely capacity limit:
  Failure and recovery behavior:
  Security boundary:
  Alternative rejected and why:
  Evidence needed before production:

"Daily volume, peak rate, concurrency and storage are not confused.", "Every diagram component has a stated responsibility.", "Caching and replication have explicit freshness and failure behavior.", "Scaling claims include the remaining shared constraints.", "The design addresses authorization, abuse and acknowledged data.", "A failure scenario changes the explanation rather than triggering a memorized slogan.", "The conclusion separates an educational sketch from production validation." ]} />

To move from an exercise to an implementation decision, use the architecture review guide. System architecture design is the related delivery scope, but this article itself serves an educational purpose.