System design interview framework

01System design: definition and purpose

System design is the process of defining components, data, interfaces and interactions that satisfy a service’s requirements. A component is a part with a specific job: an application accepts a request, a database stores searchable records, and file storage holds uploaded bytes. An interface is the agreement for asking a component to do work. The interview asks you to show how these parts cooperate and how the design behaves when traffic increases or a part fails.

You are not expected to guess a company's private architecture. You are expected to build a plausible design under stated requirements. A requirement states what the product must do or how well it must work. A tradeoff is a benefit gained by accepting a cost or limitation elsewhere. For example, keeping a second copy of an uploaded photo helps survive a disk failure, but uses more storage and requires a rule for when the upload is considered safe.

A complete answer covers requirements, workload estimates, API contracts, data ownership, component responsibilities, and failure behavior. Use one operation to verify that the proposed components form a working system. A bounded example throughout the method is a file-sharing API for PDF worksheets, with upload, download, and deletion; record 42 identifies a 2 MB PDF.

02Functional and non-functional requirements

Start by identifying actors, operations, and access rules. Clarify account requirements, file-size limits, link expiration, and revocation. These decisions determine the API and how current its permission checks must be: a public permanent link needs different read checks from a link that must stop authorizing downloads immediately after revocation.

Functional requirements: what the product does

1. Upload. An authenticated uploader can create an upload for a PDF up to 10 MB.
2. Share. Create an unlisted download link, with optional expiration. “Unlisted” means the link is hard to guess but possession permits access; private group sharing needs an additional authorization policy.
3. Download. Retrieve a permitted file through its link.
4. Delete. The owner can revoke future downloads.

These capabilities need file storage and link metadata. Collaborative editing and document grading are outside this example’s scope.

Terms used in the targets

Here, latency is the time one request takes; p95 is a threshold met by approximately 95% of the measured requests. Availability measures whether the requested operation can be used successfully. Authoritative means the component whose recorded decision is treated as truth. These terms make a requirement testable instead of merely saying “fast and reliable.”

Non-functional requirements: how well it must work

1. Performance. Start an allowed download within 200 ms at p95. Measure lookup and first-byte delay separately.
2. Correctness. A deleted link cannot start a new download. Check the authoritative deletion policy.
3. Availability. Target 99.9% successful eligible download attempts per month. Define the measurement and a failure plan.

The numeric targets here are assumptions for practice. State them, then invite the interviewer to change them.

03Workload and capacity estimates

Assume 100,000 uploading accounts, two files per account per month, a 2 MB average file, and 30 downloads per file. Use the numbers to identify the dominant work:

These figures justify separating file delivery from metadata requests. They do not establish that the metadata database needs hundreds of shards.

Interview checklist:

1. Show units. “400 GB” is storage; “400 GB/month” is growth; “1,000 requests/s” is a rate.
2. Ask about retention. Do this before multiplying monthly growth into lifetime storage.
3. Estimate to decide. Do not spend ten minutes estimating a number that will not change the architecture.

04APIs, data model and source of truth

An API is the agreement between a caller and a service. For example, use POST /worksheets with a filename, size, and expiry to create an upload session. A response returns worksheetId=42 and an upload destination. A completion call validates that the file exists before changing its state to ready. GET /links/abc123 looks up a download, and an authorized DELETE /worksheets/42 revokes future access.

Metadata is information about a file rather than the file’s own bytes. Keep one metadata row: Worksheet(id, ownerId, objectKey, objectVersion, state, expiresAt, deletedAt). The bytes live separately under an object key such as worksheets/42/v1. An object key is the storage address of the file, not the public permission to download it. The query you must support is a point lookup of one link or worksheet, so a primary-key index is a useful first choice.

A primary key uniquely identifies a database row. An index is a maintained lookup structure that helps the database find matching rows without inspecting every row. Here the link token identifies one mapping, and the worksheet ID identifies one metadata record; neither lookup needs to search the file bytes.

The initial implementation can be one application and one database plus durable file storage. Splitting APIs into many services before describing this contract adds complexity without establishing a correct request path.

The public token also needs a stored mapping: Link(token PRIMARY KEY, worksheetId). Generate an unpredictable token for an unlisted link; the short abc123 above is only a readable example, not an adequate security design. A unique owner/request-key record can make upload-session creation retryable. The file row and its request result commit together; repeating that request returns the same session rather than allocating another file.

05Worked example: upload, download and retry

Publishing a worksheet requires agreement between two stores: the metadata database and the file store. The database must not advertise a file whose upload is incomplete. An immutable object version is a particular stored version whose bytes do not change; completion verifies that version and makes the metadata point to it. The following sequence uses states to coordinate that publication.

1. An authenticated POST /worksheets validates the caller’s quota and stores row 42 with state uploading.
2. The upload writes bytes to the designated object key. The storage layer must record the complete object; an interrupted transfer does not make it downloadable.
3. The completion operation verifies a specific immutable object version, records its checksum and size, and conditionally changes row 42 from uploading to ready only if it has not been deleted. A checksum summarizes bytes so corruption can be detected. Atomic means the state transition is indivisible; another request cannot observe half of the row change.
4. GET /links/abc123 checks row 42’s readiness, expiry, and deletion state before allowing transfer.
5. An authorized delete records revocation first. Later cleanup removes unused bytes; delayed cleanup does not reauthorize the link.

The server can save a change successfully even if its response never reaches the client. Handling retries after this failure requires idempotency: repeating one logical operation must recover the same business result. If completion commits but its response is lost, retrying with the stable upload ID returns row 42’s existing ready state instead of creating another file. This failure test identifies where the deduplication record and result must be durable.

Test deletion during upload completion as well as a lost response. If deletion commits first, completion must fail its state check and leave the row deleted. If completion commits first, deletion revokes the published file. A late upload must not overwrite the verified object version. For downloads, the access check determines the order: a transfer authorized before deletion may finish; a check after deletion must reject it. If current metadata is unavailable, block new downloads. HTTP methods and object storage do not enforce these rules on their own.

06Scaling, replication and recovery

When one application cannot handle the measured peak, add stateless application instances and a load balancer, which distributes incoming requests among them. Stateless means another instance can handle the next request because essential worksheet state lives in shared durable storage. If popular public worksheets account for most bytes, a content delivery network can serve permitted cached files close to clients. Revocable/private files need a compatible authorization and cache-expiration design.

Replicate important records, decide what a successful upload promises about durability, and test restoration from backups. Replication means maintaining live copies; a backup lets you recover an older version after a bad deletion. They solve different failures.

In a 45-minute practice session, spend approximately five minutes clarifying, seven on quantities and contracts, ten drawing and tracing, fifteen on the most important bottleneck and failure, and eight reviewing. The interviewer may redirect you. Follow that signal rather than treating the time allocation as a script.

07Monoliths, modular monoliths and service boundaries

A microservices architecture separates capabilities into independently deployable services that communicate through APIs or messages. Each service controls changes to its own data; other services use its contract instead of changing its tables directly. This can help teams release independently and give a demanding component its own resources. It also adds network calls, compatibility work and more components to operate. See Martin Fowler’s discussion of microservice trade-offs.

For a concrete example, the checkout design initially keeps order creation and stock reservation in one database transaction. The application can have separate order and inventory modules without splitting that transaction across services. If browsing grows much faster than purchasing, a separate catalog search service can scale its derived product index while checkout keeps authoritative prices and stock checks together.

Splitting inventory into an independent service needs a stronger reason, such as a shared reservation capability serving several products with its own release schedule. The order and reservation would then commit separately. Define reservation expiry, retries and recovery before claiming the purchase succeeds; use the distributed-workflow lesson for that coordination. Moving code into separate processes does not make the two commits atomic.

Choose boundaries around responsibilities that can evolve independently. A diagram box may be a module, a process or a replicated service; say which you mean. Explain how a caller behaves when a service fails, because separation alone does not prevent an outage from spreading. Microsoft’s architecture guidance describes these deployment, data-ownership and failure-handling concerns.

08Interview example: explain a storage choice

Interviewer: “Why not store the PDF in the database?”

Candidate: “The database needs small records for ownership and link lookups. Our estimated 12 TB of monthly downloads is mostly file bytes, so I would put those bytes in object storage and keep their keys in the database. That allows downloads to scale independently. The added problem is publication across two stores; I handle it with uploading and ready states, and make completion retryable.”

This answer contains a choice, a workload-based reason, a new failure risk, and a concrete mechanism. If you cannot explain those four parts for a component, revisit whether it belongs in the first design.

When answering a follow-up, identify which requirement has changed before adding or replacing components in the diagram. If the interviewer changes worksheets from unlisted to private groups, the concrete new requirement is “only authorized group members may download.” Add a per-reader permission check and explain its failure behavior; the PDF storage itself does not have to change.

09The complete interview sequence

The 36 design chapters expand this method into a full practice interview. Their sections are preparation material: do not recite every paragraph or spend equal time on every stage. In a live interview, establish the complete outline, trace the central request, and use the interviewer's questions to decide which part of the design to explain in greater detail.

Draw the baseline first. When changing it, point to the failed requirement: “This cache removes repeated reads, but introduces up to 25 seconds of stale access, so it violates our original immediate-revocation promise unless we change that contract.” The change is not justified merely because a cache is conventional. A mature answer may keep the simpler design when the requirement does not pay for the added complexity.

Close in roughly 60–90 seconds: restate the requirement, describe the resulting request path, name the invariant and its mechanism, acknowledge the largest cost, and propose the next measurement. Then practise changing one requirement. Changing public file sharing to private group sharing introduces per-reader authorization and revocation; the existing object store remains useful, but the permission decision must change.

Recall the key ideas

Answer from memory before opening each card. Explain why the choice works and what it costs. Revisit missed cards tomorrow.