System Design Interview: How to Communicate Your Design

Sam Erickson
Updated 3 hours ago
0

Key Takeaways

Agree on the essential user journeys, scale, and correctness requirements before drawing components.
Estimate only what informs a decision, and distinguish assumptions from calculated results.
Explain one complete request path before exploring implementation details.
Choose a deep dive around the biggest risk, then explain your choice, its cost, and what would make you reconsider.

To communicate your design in a system design interview, make your reasoning visible: clarify the problem, estimate the relevant scale, sketch a complete solution, and explain its trade-offs. Treat each stage as a checkpoint with the interviewer rather than delivering a memorized architecture.

These system design interview tips focus on running that conversation. A worked URL-shortener example shows how to connect requirements, numbers, and design decisions without disappearing into implementation details.

Set a Lightweight Agenda

Start by proposing a plan: I'll clarify the core requirements, estimate the workload, sketch the main flows, and then explore the highest-risk part. Is there an area you'd particularly like to cover?

For a 45-minute practice round, try this budget—not an employer's scoring rubric:

5 minutes: requirements and scope.
5 minutes: useful estimates.
10 minutes: high-level design and request flows.
18 minutes: focused deep dive and trade-offs.
7 minutes: failure cases, gaps, and summary.

Adapt when the interviewer redirects you. Amazon's published system-design preparation explicitly encourages questions to complete and validate your design. Use checkpoints to invite that interaction, not to request permission for every box.

For broader preparation, see our technical interview tips. During the design itself, keep the discussion anchored to the problem.

Clarify Requirements and Scope Before Choosing Technology

Ask questions that could change your architecture. Separate functional requirements, meaning what users can do, from quality requirements, meaning how reliably, quickly, and correctly the system must do it.

Users and actions: Who uses this, and which two or three journeys matter most?
Boundaries: Are editing, search, billing, analytics, and administration included?
Workload: How many operations occur, and are requests concentrated around particular users or objects?
Correctness: Must a successful write be visible immediately? What stale behavior is acceptable?
Operations: Which latency, availability, geographic, retention, and security constraints should drive the design?

Don't ask all of these mechanically. Pick the ambiguities that matter, then propose assumptions for the rest. Microsoft's technical-interview guidance recommends clarifying ambiguities and forming a plan before implementation.

Finish with a scope statement: I'll cover creating and retrieving links, prioritize retrieval latency, and leave custom aliases and analytics out unless you'd like them included. Write that agreement beside your diagram so later decisions have a visible reference point.

Make Back-of-the-Envelope Estimates That Change a Decision

Use estimates to answer a question: Is the workload read-heavy? Could storage growth matter? Is one popular object a bigger concern than total traffic?

Average requests/second = requests/day / 86,400
Assumed peak requests/second = average requests/second * peak multiplier
Raw retained data = new records/day * bytes/record * retention days

Say the units out loud and label the peak multiplier as an assumption. Keep creates, reads, stored data, and transferred data separate.

After calculating, explain the consequence: Reads dominate writes, so I'll examine the retrieval path first. Don't turn an approximate request rate into a precise server count without assumptions about request cost, hardware, and measured capacity.

Present the High-Level Design First

Draw the smallest complete system that satisfies the agreed scope. Name responsibilities before products: request routing, application logic, durable storage, and any justified background processing.

Then narrate one write and one read from start to finish. Identify what each component receives, what it returns, and where the authoritative data lives. Label arrows with actions such as lookup mapping rather than leaving their meaning implicit.

Keep logical responsibilities separate from deployment decisions. You don't need a new service for every box; our discussion of why microservices aren't always the right starting point provides useful preparation for that choice.

Before zooming in, check alignment: That covers the basic lifecycle. I'd like to focus next on retrieval load and identifier correctness. Would you prefer a different area?

Choose a Deep Dive and Explain Trade-Offs Out Loud

Choose depth using three questions:

Which requirement is hardest to satisfy?
Where could this design fail or become expensive?
What has the interviewer asked you to explore?

Pick one or two areas, not every distributed-systems topic you know. For a messaging system, that might be delivery and ordering. For a reservation system, it might be preventing conflicting bookings.

Use this decision structure: requirement → choice → alternative → cost → reconsideration trigger. For example: I'll start with one authoritative write location to keep this flow understandable. If independent regional writes become a requirement, I'll revisit the conflict model rather than simply adding more databases.

Don't stop at it depends. Recommend an option under the current assumptions. If you're unsure about a product's exact behavior, state the property you need and what you'd verify instead of inventing a guarantee.

Worked Example: Communicating a URL-Shortener Design

The following is a hypothetical exercise. All traffic figures and targets are illustrative assumptions, and the suggested wording is not a transcript of a real interview.

1. Agree on the Contract

Suppose the prompt is simply Design a URL shortener. Start by asking whether users need custom aliases, expiration, destination editing, and analytics. Also clarify when a newly created link must become usable.

For this example, agree on:

Create a short link and resolve it to its destination.
Keep destinations immutable; exclude custom aliases, expiration, and analytics.
Make a link usable immediately after successful creation.
Assume one serving region and retain mappings for one year.
Use a hypothetical p95 resolution-latency target below 100 milliseconds, measured at the service boundary and excluding destination-page loading.

Define p95 plainly: the target is for at least 95% of resolution requests to finish below that threshold. Flag authentication, creation-rate limits, and abuse handling as requirements to revisit rather than silently implying that the sketch is a launch-ready public service.

2. Estimate the Workload and Interpret It

Assume 10 million creates and 1 billion resolutions per day, a 10× peak multiplier, and 500 bytes of raw mapping data per record.

Average creates:       10,000,000 / 86,400 ≈ 116/second
Average resolutions: 1,000,000,000 / 86,400 ≈ 11,600/second
Assumed peak: approximately 1,200 creates/second
              approximately 116,000 resolutions/second
Raw mapping growth: 10,000,000 * 500 bytes = 5 GB/day
One year of raw mappings: 5 GB * 365 = 1.825 TB

These storage figures use decimal units and exclude indexes, replication, backups, and other storage overhead.

Explain the implication: The workload has 100 resolutions per create. I'll focus on retrieval capacity and repeated lookups, while keeping storage growth visible. These numbers don't establish that a particular database deployment can handle the load; that still needs capacity testing.

3. Sketch and Walk Both Paths

Client --> Request routing --> Link application
                                   |
                                   +--> Shared cache: code -> destination
                                   |
                                   +--> PostgreSQL: authoritative mappings

Create:  validate -> generate code -> commit mapping -> return link
Resolve: cache lookup -> database on miss -> populate cache -> redirect

Propose a mapping containing code, destination_url, and created_at. Choose code as the primary key. PostgreSQL primary keys enforce unique, non-null values, as documented in its constraint documentation.

For creation, propose generating a random candidate and attempting the insert. On a code conflict, generate another candidate with a bounded retry policy; don't make a separate existence check your correctness mechanism. Return success only after the mapping transaction commits.

For resolution, use the shared cache first and query the authoritative database on a miss. That's cache-aside: the application loads missing data from storage and adds it to the cache. In this design, don't cache missing codes or introduce asynchronous read replicas yet; keep the immediate-use requirement explicit.

For successful resolution, propose an HTTP 302 response with the destination in Location. MDN documents 302 as a temporary redirect. Leave browser and edge caching out of this initial sketch rather than treating them as interchangeable with the application cache.

4. Go Deep on the Read Path and Its Failure Modes

Explain why you chose this area: Resolution carries most of the traffic, so I'll examine popular links, cold-cache behavior, and database protection.

A cold or unavailable cache can shift traffic onto the database. AWS's caching guidance discusses this failure mode and mitigations including request coalescing and load shedding. Request coalescing combines simultaneous lookups for the same uncached item; load shedding rejects excess work to protect capacity.

Propose bounded database concurrency during cache failures and test that degraded mode. For popular links, examine cache-key concentration instead of assuming traffic spreads evenly. Track resolution latency, cache hits and misses, and database request volume.

Then state the trade-off: The cache is a candidate for reducing repeated database reads, but it adds another failure mode and freshness policy. I'll validate lookup reuse before relying on it.

If the interviewer adds urgent abuse takedowns, acknowledge the changed requirement. Cache-aside doesn't guarantee consistency between the cache and backing store. Revisit invalidation, stale in-flight fills, and acceptable takedown delay rather than promising that a cache deletion makes every reader current.

5. Close With a Decision Summary

Finish with the design's argument, not another tour of the boxes: This design covers creation and resolution, acknowledges writes after commit, and focuses caching on the dominant read path. Before calling it production-ready, I'd validate peak and cold-cache capacity, specify retention cleanup and recovery, and resolve abuse-handling requirements.

That ending distinguishes what you've established from what remains an open design task.

Common Mistakes

Silent drawing: Explain the decision behind each addition, not just the component's name.
Premature detail: Finish the basic request path before discussing partition algorithms or deployment configuration.
Unlabeled guesses: Mark assumptions visibly and update the consequences when they change.
Defending the first design: Treat new constraints as reasons to revise, not objections to defeat.
No closing summary: Reserve time to connect requirements, decisions, and unresolved risks.

FAQ

How should I start a system design interview?

Restate the problem, clarify the essential user journeys and quality requirements, and agree on scope. Then propose a short plan before drawing the architecture.

How much estimation should I do?

Estimate enough to inform a design decision, such as prioritizing reads, planning retention, or investigating a bottleneck. State assumptions and units, then explain what the result changes.

How do I choose where to go deep?

Choose the area where a key requirement meets the greatest correctness, capacity, or failure risk. Explain why that area deserves attention and invite the interviewer to redirect you.

What should I say when I don't know a technology?

Describe the behavior you need, identify what you're uncertain about, and explain what you'd verify. Continue with an explicit assumption instead of inventing an API, limit, or consistency guarantee.