System Design Interview Framework

Advanced System Design & Software Architecture · Lesson 66 · Architecture Practice, Interviews and Capstone

Lesson Overview

A TechLearningPro staff candidate spent the first eight minutes of a forty-five-minute loop drawing a gateway, a cache, a log, a second region, and a stream processor for "design a feature-flag service used by the classroom." The interviewer asked what the write rate was. The candidate said "high." Asked what a learner sees when the flag store is down, the candidate added another box. The packet never named a user, a number, an API, or a decision. The committee scored communication as confident and the design as unscored, because there was nothing to score. The candidate was strong in production. The hour measured a different skill: turning an ambiguous prompt into a defensible design before the clock ends.

This lesson is that skill. High-Level System Design Methodology is the sequence you use when you have a day and a review. The interview is the same sequence with a published clock, a smaller surface, and a rubric a hiring panel can apply twice and get the same band. The seven moves are clarify, estimate, API, data, high-level design, one deep dive, and trade-offs. You leave each move with an artifact the interviewer can point at: a scope sentence, a labeled assumption, a contract, an owner, a diagram, a failure, and a reopen condition.

The primers at /learn/system-design/interview-framework and /learn/high-level-design/home name the outline. They do not tell you what to do at minute thirty-two when the interviewer says "go deeper on matching," or how a panel distinguishes a solid senior loop from a staff loop. This lesson does. The worked hour is a compressed pass over Dispatch, the ride product from Design a Ride Booking Platform. The second worked hour is a TechLearningPro exam-window quiz intake. Both are scored with the same rubric. Lesson 67 practices the low-level cut of this clock. Lesson 68 practices the high-level cut on the Module 5 case studies. The rubric here is the one those drills use.

You will leave able to run a forty-five-minute design, recover when a number is wrong, and grade a recording without debating taste.

Learning Objectives

By the end of this lesson you will be able to:

1. State what a system-design interview measures, and which production skills it leaves unmeasured.
2. Run seven moves in order: clarify, estimate, API, data, high-level design, deep dive, trade-offs.
3. Allocate a forty-five-minute loop and a sixty-minute loop, and say what you drop when you are behind.
4. Ask a short requirement set that separates users, operations, consistency, latency, security, and scope.
5. Publish assumptions with units, compute one bottleneck, and correct a bad number in public.
6. Sketch an HTTP contract with success, conflict, absence, and a user-visible failure.
7. Assign each stored fact to one owner and name the access path the diagram must serve.
8. Draw a high-level design whose boxes have responsibilities and whose arrows have a protocol.
9. Choose a deep dive from the riskiest component, and follow when the interviewer moves you.
10. Close with one decision, the option you refused, and the measurement that reopens it.
11. Score a loop with the TechLearningPro rubric so two reviewers land in the same band.
12. Tell a senior loop from a staff loop using operability, migration, and organizational constraint.

Prerequisites

• Lesson 23, the design sequence. This lesson compresses it. It does not replace the requirement that every number is labeled and every failure has a user-visible result.
• Lesson 24, capacity estimation. Interview arithmetic uses the same unit discipline. Peak factor stays an assumption.
• Lesson 10, architecture documentation and ADRs. The closing trade-off is a one-paragraph decision record.
• Lesson 61, staff-engineer architecture decision-making, for the extra questions a staff loop asks about reversibility and who operates the system.
• Lesson 62, non-functional requirements and SLO design. In the interview you state one latency target and one availability target. You do not design an SLO program.
• Comfort with HTTP status semantics in RFC 9110. The interview contract uses those codes. It does not invent a private status vocabulary.
• Module 5 case studies are examples you may be asked to compress. You do not need to recite them. Lesson 68 is the drill.

Detailed Core Concepts

What the hour is for

A system-design interview is a structured conversation about a design you build in the room. The prompt is incomplete on purpose. The interviewer has a private list of probes: a consistency edge, a hot key, a failure, a security boundary. Your job is to make the design inspectable fast enough that those probes have somewhere to land.

Four signals are scored. Problem navigation is whether you shrink the prompt before you draw. Technical correctness is whether the mechanism you name can do the job you assigned it: a conditional update that actually prevents two riders from taking one driver, a cache whose staleness matches the disable rule, a queue that is allowed to lag. Trade-off judgment is whether you can say what you gave up and what would change your mind. Communication is whether a second interviewer, reading only your notes, can reconstruct the design.

The hour does not measure whether you can operate the system at 3 a.m., whether your code compiles, or whether you know a vendor's current SKU list. Naming a product does not earn the point. Explaining the invariant does.

The seven moves

The moves are ordered because each one constrains the next.

1. Clarify. Write the users, the one workflow you will design, the quality bar, and the list you are leaving out. Stop after a handful of questions. When the interviewer says "you choose," write the choice as an assumption.
2. Estimate. Turn the workflow into rates and bytes. Label every input. Name the first resource that saturates. If you cannot compute it, you are still clarifying.
3. API. Name the operations a client calls. For each: who calls it, the idempotency rule, the success body, and the status when the thing is missing, conflicting, or the dependency is down.
4. Data. Name the entities, the owner, the primary access path, the consistency you need on that path, and what you refuse to store.
5. High-level design. Draw only the boxes required by the API and the data. Every box has one job. Every arrow is a protocol you can say out loud: HTTPS, SQL, a cache get, a published event.
6. Deep dive. Pick the component where a wrong mechanism breaks the product. Stay there until the interviewer moves you. Have a second dive ready.
7. Trade-offs. State the decision, the alternative, the cost, and the reopen condition. Tie it to a number from the estimate.

Skipping estimate and jumping to boxes is how the feature-flag loop failed. Skipping the API is how a diagram becomes a poster. Skipping the trade-off is how a correct diagram still scores as a recitation.

The clock

A forty-five-minute loop and a sixty-minute loop use the same moves. The sixty-minute loop buys a second deep dive and a cleaner close. It does not buy a second product.

When you are three minutes over on clarify, you shorten the API, not the deep dive. The deep dive is where correctness is scored. When you are lost inside the deep dive at minute forty, you surface, state what you have, and spend the last minutes on the trade-off. A finished shallow design outscores an unfinished masterpiece.

Write the clock in the corner of the board. Check it at the end of each move. The check is part of communication.

Clarify without stalling

Useful questions have a design consequence. "Who creates a trip, and who is allowed to cancel it?" changes the API. "Is a fare quote binding?" changes the data model. "What does the rider see if no driver is near?" changes the failure behavior. "Are we designing one city or every city on earth?" changes the estimate.

Questions that do not change the design are small talk: which cloud, which language, which shade of microservice. Pick a boring default, say it, and move. TechLearningPro's default in this course is one region, a relational primary for the system of record, HTTPS at the edge, and a language-agnostic service boundary. Java appears when a contract needs to be executable. The interview does not require a framework tour.

Six to eight questions is enough. Then read the scope back in one sentence: "I am designing trip request, match, and complete for one metro, with location updates as the hot path, and I am leaving surge pricing and multi-city sharding for a reopen condition." That sentence is the contract with the interviewer. If they wanted payments in scope, they will say so now, while you still have time.

Separate four lists on the board, even if each list is three bullets:

• Behavior. What the user can do.
• Quality. One latency number, one availability hope, one consistency invariant.
• Constraints. Team size, one region, no card data, a retention limit.
• Assumptions. Numbers and product choices the interviewer did not give you.

Lesson 62's full quality-attribute scenario is the right tool in a design review. In the interview, one sentence is the scenario: "A rider in the metro requests a car at peak and sees a match or a clear no-match within two seconds, excluding the driver's physical arrival."

Estimates that can be attacked

An estimate is a product of labeled assumptions. The interviewer is allowed to change an assumption. You recompute. You do not defend the old number.

Use units in the name. tripsPerDay, not traffic. Convert daily volume to a peak per second with an explicit peak factor. The factor is a guess. Say so. A peak factor of 10 means you believe one tenth of the day carries the peak. For a commute product that may be low. For a uniform API it may be high.

Name storage only for the thing that grows. A trip row of about one kilobyte and a location sample of about one hundred bytes lead to different decisions. Location history is the retention problem. Trip rows are not.

End the estimate with one sentence: "The first saturated piece is driver location ingest, at this many writes per second, and trip create is two orders of magnitude smaller, so I will not shard the trip table for this brief." That sentence decides the diagram. A diagram that shards the quiet table and ignores the hot one has failed the estimate even if the arithmetic was pretty.

Order of magnitude is the goal. A factor-of-two error is normal. A factor-of-a-thousand error means a unit mistake, and you should hunt it before you draw. Multiplying by 86,400 twice, or forgetting that peak is per second, is the usual bug. Write the unit beside the number.

APIs that survive a retry

Interview APIs are small. Three to five operations. For each, say the caller, the authz rule in one line, and the retry rule.

Prefer resources and HTTP methods you can defend from RFC 9110. POST /trips creates. A repeated POST with the same Idempotency-Key and the same body returns the original trip. The same key with a different body is a conflict. GET /trips/{id} is safe to retry. POST /trips/{id}/cancel is idempotent in effect: a second cancel of an already cancelled trip returns success and the cancelled representation. Use 404 for unknown ids, 409 for an illegal state transition, 429 when a limiter refuses, and 503 when a required dependency is down and the client should retry later. 200 with an error string in the body wastes the interview and hides the contract.

Pagination, if you mention a list, is a cursor. Say why an offset page tears under inserts. Then stop. Do not design five list endpoints.

Write the idempotency key as a header on unsafe creates. The course uses Idempotency-Key. The behavior is the one in Idempotency and Exactly-Once Processing: store the key with a hash of the request, replay the stored response, reject a mismatched body. You do not need to re-teach the inbox and outbox unless the deep dive goes there.

Data ownership

Every fact has one writer. The trip row is owned by the trip service. The latest driver location is owned by the location ingest path. A cache of "drivers near this cell" is a derived view with a stated age. If two boxes both update trip status, you have two writers, and the interviewer's next question will be which one wins.

Say the access path that justifies the model. "Match reads drivers whose last point falls in the geohash cells around the pickup, then attempts a conditional update on one driver." The index serves that read. The index is not the assignment. Lesson 53 makes the same split. In the interview you say it in two sentences and move.

Say what you do not store. Card numbers stay at the payment provider. Precise location history has a retention window and an access reason. A design that keeps every GPS point forever "for machine learning" has created a privacy incident and a storage bill. Name both.

Consistency is a sentence about one invariant. "At most one in-progress trip per driver" is enforced by a conditional update on the driver row or on the trip row, in one database. You do not need a distributed lock service for that sentence. If you reach for a lock service, say which invariant crosses process boundaries. Lesson 36 is the reference. The interview wants the invariant first.

The diagram

A high-level diagram in an interview is a handful of boxes. Clients, an edge, the service that owns the trip, the store, the location index, and a payment port if money is in scope. Draw a trust boundary around anything that receives a caller-supplied location or a payment token.

Inside each box, write the responsibility, not the product name. "Trip state machine" is a responsibility. A trademark is not. Arrows get verbs: "conditional update," "publish trip-completed," "authorize with provider token." If you cannot name the verb, the arrow is decoration.

Leave space under the diagram. The deep dive will annotate one box. A diagram that fills the board leaves you talking in the air.

The deep dive

The right dive is the place the product breaks. For Dispatch it is the match: how a nearby search becomes a single winner. For a shortener it is the redirect path and the allowlist. For a feed it is fan-out amplification. For payments it is the timeout that must not capture twice.

Announce the choice. "I am going deep on match, because a wrong lock there double-assigns a driver. I can go deep on location retention if you prefer." This gives the interviewer a steering wheel. They often have a script. Let them use it. Fighting to stay on your favorite box scores as poor navigation.

Inside the dive, go one level down, not five. Algorithm, data structure, failure, and the user-visible result. Pseudocode is welcome when it is short. A class hierarchy is a low-level interview, which is lesson 67. If the interviewer asks for classes, switch frameworks. Say that you are switching.

When you are stuck, narrate the invariant you are protecting and the two mechanisms you are choosing between. Silence hides partial credit. A wrong mechanism you correct out loud scores higher than a frozen board.

Trade-offs and the staff extra

Close by speaking a decision record:

• Decision. One metro, one relational primary, geohash cells for candidate drivers, conditional update for assignment.
• Refused. A cell-sharded matcher and a second region on day one.
• Cost. A single primary is the availability ceiling. Location ingest must be trimmed or sampled before it overwhelms that primary.
• Reopen. When sustained location writes exceed what one primary can take with headroom you measured, or when a contract requires another region.

A senior candidate who does this clearly can score "solid." A staff candidate also says who is on call, how the design migrates from the spreadsheet Dispatch replaced, and which decision is reversible. Lesson 61 is that extra. You do not spend the senior clock on an org chart. You do spend one sentence: "The trip service is the only writer, so the on-call scope is one datastore and one deployable."

The scoring rubric

TechLearningPro's loop uses six dimensions. Each is scored 1 to 4. Weights reflect what the hour can actually show. A 4 is rare and specific. A 3 is a hire signal on that dimension. A 2 is mixed. A 1 means the signal was missing or actively misleading.

Weighted 3.0 is a solid senior pass at TechLearningPro. Below 2.5 is a no-hire on this loop even if one dimension was excellent. A 4 on deep dive does not cancel a 1 on navigation, because the panel cannot trust the dive was about the right problem. Staff loops use the same weights and expect the trade-off row to include operability and migration. They do not add a seventh mystery dimension in the room.

Write the score from evidence on the board. "They said Kafka" is not evidence. "They specified a conditional update and the lost-update it prevents" is evidence.

Architecture and Design Diagrams

The interview is a pipeline of artifacts. Time flows down. A later box may send you back when the interviewer changes an assumption. The return edge is part of the method.

mermaidCopy
flowchart TD
    subgraph clock45 [Forty-five minute loop]
        C[Clarify 0 to 6 min]
        E[Estimate 6 to 12 min]
        A[API 12 to 18 min]
        D[Data 18 to 24 min]
        H[HLD 24 to 33 min]
        V[Deep dive 33 to 41 min]
        T[Trade-offs 41 to 45 min]
    end
    C --> E
    E --> A
    A --> D
    D --> H
    H --> V
    V --> T
    E -->|assumption challenged| E
    V -->|interviewer redirects| V
    T -->|reopen condition| E

The conversation around that pipeline has a rhythm. You offer a scope sentence. The interviewer either accepts it or tightens it. You compute. They change one assumption. You adjust the diagram before the dive, so the dive is about the design you actually claimed.

mermaidCopy
sequenceDiagram
    participant Cand as Candidate
    participant Int as Interviewer
    Cand->>Int: Scope sentence and out-of-scope list
    Int->>Cand: Accept, or add one workflow
    Cand->>Int: Labeled assumptions and bottleneck
    Int->>Cand: Change one assumption
    Cand->>Int: Recomputed bottleneck and revised boxes
    Cand->>Int: Offer two deep dives
    Int->>Cand: Pick one
    Cand->>Int: Mechanism, failure, user-visible result
    Cand->>Int: Decision, cost, reopen condition

A third view is the rubric as a gate. Evidence is collected during the moves. The score is applied after the loop, not negotiated inside it.

mermaidCopy
flowchart LR
    Board[Board artifacts] --> Ev[Evidence notes]
    Ev --> Nav[Navigation]
    Ev --> Est[Estimation]
    Ev --> AD[API and data]
    Ev --> HLD[High-level design]
    Ev --> Dive[Deep dive]
    Ev --> Trade[Trade-offs]
    Nav --> Score[Weighted band]
    Est --> Score
    AD --> Score
    HLD --> Score
    Dive --> Score
    Trade --> Score

Read the first diagram as a budget. Read the sequence as the social contract. Read the third as the reason the artifacts exist. A beautiful diagram that never states a bottleneck cannot feed the estimation node, and the weighted band stalls.

Technical Explanation

Board hygiene

Divide the board into four regions before you draw a box: scope, numbers, contract, picture. The picture region must be large enough for one dive annotation. If you are in a shared document, use four headings instead of four board regions. The headings are the same.

Write assumptions in a column you can strike through. When the interviewer doubles the daily trips, strike the old peak and write the new one beside it. Leave the old one visible. The correction is evidence for the estimation score.

Speak in the present tense about the design you are choosing. "The trip service owns status" is a decision. "We could maybe have a service" is a delay.

Defaults that keep you moving

State a default pack once, then stop repeating it.

• One geographic region unless the prompt says users on two continents with a latency budget that forbids a round trip.
• A relational database as the system of record for invariants that fit on one primary at the estimated write rate.
• A cache only after you name the read it saves and the staleness it is allowed to serve.
• A queue only after you name the work that is allowed to be asynchronous and what the user does while it is in the queue.
• HTTPS, authentication at the edge, authorization in the service that owns the data.
• No card data, no precise location kept beyond a stated retention, no secrets in the event payload.

These defaults are reversible. Saying them prevents a twenty-minute detour through a vendor catalog.

Arithmetic you can do without a calculator

Keep a small set of constants on the side of the board. 10^5 seconds is about a day. 86,400 is the exact day. 10^6 seconds is about 11.6 days. A kilobyte is 10^3 bytes when you are estimating order of magnitude, and you say that you rounded. Peak QPS is daily count times peak factor, divided by 86,400.

A Java check helps you practice the arithmetic before the interview so the units are boring on the day. This is application code. It encodes the formula. It does not call a capacity-planning product.

javaCopy
public final class InterviewEstimate {
    private InterviewEstimate() {}

    /** Peak requests per second from a daily count and a unitless peak factor. */
    public static double peakPerSecond(long perDay, double peakFactor) {
        if (perDay < 0 || peakFactor < 1.0) {
            throw new IllegalArgumentException("perDay >= 0 and peakFactor >= 1");
        }
        return (perDay * peakFactor) / 86_400.0;
    }

    /** Bytes retained for a stream of fixed-size samples. */
    public static double retainedGibibytes(long samplesPerDay, int bytesPerSample, int days) {
        if (samplesPerDay < 0 || bytesPerSample < 0 || days < 0) {
            throw new IllegalArgumentException("negative input");
        }
        double bytes = (double) samplesPerDay * bytesPerSample * days;
        return bytes / (1024.0 * 1024.0 * 1024.0);
    }
}

Run it on paper with the same inputs you will use in the room. If peakPerSecond(5_000_000, 10) surprises you, you have a unit bug in your intuition, and the interview is a bad place to meet it for the first time.

What to do when the number is wrong

Interviewers change the number to see if the design was load-bearing. Three responses are good.

• The bottleneck stays the same. Say so, and leave the diagram.
• The bottleneck moves. Change one box. Explain the move in a sentence.
• The new number is outside anything you would run on one primary. Say the reopen condition just fired, and name the next design in outline only: partition key, what remains global, what gets worse.

A bad response is redrawing the entire board for a two-times change. A worse response is keeping a planet-scale diagram after the interviewer says "this is one campus."

Probes and how to take them

Common probes and the move they belong to:

Answer the probe at the depth asked, then ask whether to stay there. Extending every probe into a new subsystem is how the clock dies.

Senior loop and staff loop

Both loops use the seven moves. The staff prompt is often a system that already exists. "We have a modular monolith. Design the extraction of enrollment." The extra content is a migration step, a compatibility window, and a rollback. Lesson 48 is the course reference. In the room you need one slice: dual-write or strangler, who the system of record is during the window, and how you know the slice is done.

The senior prompt is usually a product from a cold start. Do not volunteer a migration you were not asked for. Do volunteer the operational sentence: one on-call surface, one system of record, one deployable that owns the invariant.

What the interviewer writes down

Assume the interviewer has a form with the six dimensions and a few required probes. They are trying to tick evidence, not to admire drawing skill. Short sentences that contain a mechanism are easier to tick than long speeches that contain a brand. "Conditional update on driver_id where state is free" can be quoted in the debrief. "We will use a fast in-memory store" cannot.

If you notice a required probe was not asked, and you have two minutes, you may offer it. "The failure I want on the board is a timeout from the payment provider while the trip is completing." That is navigation. It is also a gift to a tired interviewer.

Practicing the clock

Practice with a visible timer and a blank page. Stop at the end of each move and check that the artifact exists. Record yourself once a week. Score the recording with the rubric the next day, when you can no longer hear your intention, only your words. The gap between what you meant and what you said is the gap the panel hears.

Rotate prompts. A week of only ride-sharing teaches a script. The framework is the transferable piece. Lesson 68's URL shortener, feed, and payments drills exist so the script cannot harden.

Practical Implementation or Design Walkthrough

This walkthrough is a forty-five-minute Dispatch loop. It is the interview cut of lesson 53. The full packet, including the schema and the scale path across cities, stays in that lesson. Here the point is what lands on the board before the clock ends.

Minute 0–6: clarify

The prompt is "design a ride booking service." You ask:

1. Are we matching riders and drivers in one metro, or worldwide?
2. Is the core loop request, match, track, complete, and cancel?
3. Does the rider lock a fare at request time?
4. What should the rider see if no driver accepts within the wait?
5. Do we store raw GPS trails, and for how long?
6. Are payments in scope beyond "charge the locked fare at complete"?

The interviewer says: one metro, that loop, fare locked at match, rider sees "no cars" after a short wait, keep raw trails for seven days for safety disputes, payments are a charge at complete through an external provider. You write:

Scope. One metro. Request, match, en-route location, complete, cancel. Fare locked at match. Seven-day location retention. Provider charges the locked amount at complete. Card data stays at the provider.

Out of scope. Surge, multi-city sharding, in-app chat, driver payroll.

Quality. Match or no-match returned within two seconds at peak. A driver has at most one in-progress trip. Availability target for the trip API is 99.9% for the month, excluding the provider.

Assumptions you add, out loud. 500,000 trips per day in the metro. 20,000 active drivers at peak. Each active driver sends a location every four seconds. Peak factor 5 on trips, because commute hours dominate. Average trip row 1 KB. Location sample 100 bytes.

Minute 6–12: estimate

Trips at peak: 500_000 * 5 / 86_400 ≈ 29 creates per second. That is a quiet relational primary.

Location samples: 20,000 drivers / 4 seconds = 5,000 writes per second sustained at peak, not a spike. Seven-day retention: 5,000 * 86_400 * 7 * 100 bytes. Compute it as 5,000 * 86,400 = 4.32e8 samples per day, times 7 is about 3.0e9 samples, times 100 bytes is about 3.0e11 bytes, about 280 GiB. Say "order of 300 GiB of location history, on a clock that must accept 5,000 writes per second."

Bottleneck sentence. Location ingest dominates. Trip create does not justify sharding. The location store needs a write path that can drop or batch samples. The trip invariant stays on one primary.

If the interviewer says "make it 50,000 drivers," ingest becomes 12,500 writes per second and retention about 700 GiB. You say the trip primary is still fine, and the location path needs batching or a log. You do not introduce a second trip database.

Minute 12–18: API

Authorization in one line: a rider reads and cancels only their trip; a driver accepts only a trip offered to them; location posts are bound to the authenticated driver id.

Minute 18–24: data

• Trip. Owner: trip service. Access: by id, and by driver id for "my current trip." Invariant: status transitions are checked in SQL. Fare locked is a column set once at accept.
• Driver availability. Owner: trip service, same database. A driver row has state free or busy. Accept is a conditional update.
• Location sample. Owner: location ingest. Access: latest point per driver, keyed so match can read a cell. History retained seven days, then deleted by a job whose failure does not affect match. Match reads latest points, not the history table.
• Charge. Owner: payment provider. We store the provider's charge id and our idempotency key. We store a token reference if the provider issued one. We do not store a PAN.

Index for match: a geohash, or an H3 cell id if you use that open library, on the latest location. Say the precision you would start with, and that the cell is a candidate filter. Assignment is the conditional update, not the presence of a point in a cell.

Minute 24–33: high-level design

Draw five boxes.

• Rider and driver apps, outside the trust boundary.
• Edge: authenticates, rate-limits POST /trips and POST /locations.
• Trip service: the only writer of trip status and driver busy state.
• Location ingest: accepts samples, updates latest-by-driver, appends history.
• Payment port: calls the provider's published HTTPS API with an idempotency key. The URL is configuration.

Match runs inside the trip service. It asks location ingest for candidate driver ids in nearby cells, then conditional-updates one driver from free to busy and the trip from REQUESTED to ACCEPTED in one transaction. If the update affects zero rows, it tries the next candidate. If the candidate list is empty, the trip stays REQUESTED until the wait expires, then becomes NO_MATCH.

Events: TripCompleted is published after the local transaction commits, for receipts and analytics. The charge itself is in the complete path because the prompt put money at complete. Say the tension: a provider timeout leaves the trip COMPLETING and a reconciliation job asks the provider by idempotency key. You do not mark the trip completed and also show the rider an error.

Minute 33–41: deep dive on accept

You offered match and payment timeout. The interviewer says match.

The bug you are preventing: two drivers accept one trip, or one driver accepts two trips. One transaction:

sqlCopy
UPDATE driver
   SET state = 'busy', current_trip_id = :tripId
 WHERE driver_id = :driverId
   AND state = 'free';

If the update count is zero, this driver lost a race or went offline. Do not offer them the trip. In the same transaction, update the trip from REQUESTED to ACCEPTED where trip_id = :tripId and status is still REQUESTED. If that update count is zero, roll back the driver update. The database, not a lock service in another process, is the linearization point.

Failure: location ingest is down. Match returns 503 on new requests that need candidates, and in-progress trips still complete because they do not read the cell index. Failure: the transaction deadlocks under contention on a celebrity driver. You retry the transaction a bounded number of times, then return 409 to the losing accept. The rider still has a trip in REQUESTED until a winner commits or the wait expires.

You mention a test: two threads call accept for the same trip, exactly one gets 200, the other gets 409, and the driver row shows one current_trip_id. That sentence is the difference between a 3 and a 4 on the deep dive.

Minute 41–45: trade-offs

Decision. One relational primary for trips and driver state. Location latest-points separated so 5,000 writes per second do not sit on the trip transaction.

Refused. A global lock manager. The invariant is one row.

Refused for now. Sharding trips by city. We have one city, and 29 creates per second.

Cost. Location history at ~300 GiB per week of retention is an operational object. The delete job is part of the design. Match correctness does not depend on it.

Reopen. Location writes above what a single latest-point store can take with headroom, or a second metro that must fail independently.

Staff sentence, if this were a staff loop. Replace the spreadsheet one venue at a time. The trip table is the system of record the week that venue cuts over. Rollback is "venue flag off," and in-flight trips drain. On-call owns trip service and location ingest as two alerts, one playbook each.

Score of this loop

Navigation 4, estimation 3, API and data 4, high-level design 3, deep dive 4, trade-offs 3. Weighted: 0.15*4 + 0.15*3 + 0.20*4 + 0.15*3 + 0.25*4 + 0.10*3 = 3.55. A strong senior hire signal. The missing 4s are the rough retention arithmetic and a diagram that a reviewer would still want drawn more carefully in a real design doc. The interview does not require the doc. Lesson 69 is where that doc gets reviewed.

Enterprise Real-World Scenarios

Scenario 1: hiring loop for a mobility team

A mobility company asks a TechLearningPro instructor, who is changing roles, to design ride booking in forty-five minutes. The private probe list is double-accept, fare lock versus final charge, and GPS retention. The candidate spends fifteen minutes on surge pricing formulas and draws a Kubernetes cluster. At minute thirty they have no trip state machine.

Score the loop with the rubric before you discuss "culture." Navigation 1, because surge was never accepted into scope. Estimation 1, no rates. API and data 2, a few URLs, no invariant. High-level design 2, a cluster diagram. Deep dive 1, the probe never had a home. Trade-offs 1. Weighted under 1.5. The debrief quote is: "Could not protect a single-driver invariant." The kind sentence in the rejection is optional. The evidence is not.

The repair, for the next candidate or for a re-loop, is the walkthrough above. The panel is not looking for the lesson 53 schema from memory. They are looking for the conditional update and the bottleneck sentence. A candidate who says "I would check lesson 53's packet" has missed the point of a closed-book hour. A candidate who reconstructs the invariant has passed the part that matters.

Scenario 2: exam-window quiz intake at TechLearningPro

A university tenant runs a proctored exam. 40,000 learners click "begin" inside a five-minute window. Then they submit answers for ninety minutes. The prompt in an internal staff practice loop is "design quiz attempt intake." The clock is forty-five minutes. Payments, video proctoring, and the item bank are out of scope. The invariant is: one open attempt per learner per exam, and a submit either stores the answers the learner sent or fails clearly.

Clarify gets you that window. Estimate it before you draw. 40,000 begins / 300 seconds is about 133 begins per second if the window is flat, and higher if they cluster in the first thirty seconds. Assume a peak factor of 4 on that already-short window: about 500 begins per second for a brief spike. Submits are larger bytes, spread over ninety minutes: if each learner submits once, 40,000 / 5,400 seconds is under 10 submits per second average, with a final-minute spike. Call the final minute 40,000 / 60 ≈ 670 submits per second if everyone finishes together. The interviewer may say "they do." Now the hot write is the final-minute submit, not the begin.

API: POST /exams/{id}/attempts with Idempotency-Key, PUT /attempts/{id}/answers as a full replace of the draft, POST /attempts/{id}/submit idempotent. Data: an attempt row owned by the exam service, unique on (exam_id, learner_id) where state is open. Deep dive: the unique constraint plus a transaction that inserts the attempt, and the submit path that flips OPEN to SUBMITTED with a conditional update so two tabs cannot double-submit different bodies. The second submit with the same body replays. A different body after SUBMITTED is 409.

Trade-off: accept that a draft save is allowed to be last-write-wins every few seconds, and that submit is the linearization point. Refuse a per-keystroke synchronous write to the primary. Reopen if answer bodies exceed a size you state, for example 1 MB, and you need object storage for attachments. That is a different product, closer to lesson 58.

This scenario scores the same rubric. A candidate who designs for 40,000 steady QPS has failed estimation, because the begins are a five-minute event and the submits are a ninety-minute event with a cliff. A candidate who sizes the cliff and protects the unique attempt has a hire signal. The exam is also a tenancy problem: the attempt row carries tenant_id, and the unique key includes it. Lesson 60's rule applies even in a sketch. Say it in one sentence so the panel hears that you did not design a single-tenant toy on top of a multi-tenant platform.

What the two scenarios share

Ride matching and exam submit look different and score the same way. Both need a scope sentence, a peak that is a burst rather than a flat day, one invariant enforced in one datastore, an idempotent unsafe call, and a reopen condition. Practicing only the ride prompt teaches the wrong lesson if you memorize cells and forget the rubric. Alternate the prompts. Score both recordings. The band should move because your habits moved, not because you bought a story.

Best Practices

• Put the clock on the board and protect the deep dive when you run long.
• Read the scope back as one sentence before any box is drawn.
• Label assumptions with units. Recompute when a single input changes.
• End estimation with the resource that saturates first, and delete boxes that resource does not need.
• Give every unsafe create an idempotency rule and every state change a legal-transition rule.
• Name one writer per fact. Call caches and indexes derived.
• Draw protocols on arrows and a trust boundary around caller-supplied data.
• Offer two deep dives and take the one the interviewer picks.
• Close with a decision, a refusal, a cost, and a reopen condition tied to a number.
• Score practice recordings with the weighted rubric the next day.
• For a staff prompt, add one migration slice and one on-call surface. Keep it to a few sentences.
• Prefer boring defaults. Spend the clock on the invariant.

Common Mistakes and Anti-Patterns

The technology poster. The board lists a gateway, a cache, a log, a mesh, and a warehouse in the first ten minutes. It happens because diagrams in blog posts are shaped that way, and because silence feels risky. The consequence is an unscored design. The repair is the artifact rule: no box until the scope sentence and the bottleneck exist.

The unscoped planet. The prompt is a campus quiz, and the design shards by region worldwide. It happens because "scale" is treated as a compliment. The consequence is a deep dive on a router instead of on the unique attempt. The repair is to ask "one campus or many?" and to let the estimate delete regions.

Numbers without units. "A million users" is used as QPS, as storage, and as a team size. It happens under stress. The consequence is a bottleneck that moves by a thousand when the interviewer asks a follow-up, which looks like guessing. The repair is InterviewEstimate on paper until the conversions are dull.

The happy-path API. Every call returns 200 and a boolean. Retries create a second trip or a second attempt. It happens because status codes feel like trivia. The consequence is a failed probe on double-submit, which is the most common probe in this course's loops. The repair is four statuses you can defend: success, 404, 409, 503.

The second writer. A cache, a worker, and the API all update status. It happens when each box is designed locally. The consequence is an invariant you cannot point at. The repair is to name the owner before you add a worker. Workers consume events. They do not author the status the event described, unless they own a different fact.

The recitation. The candidate speaks a memorized ride-sharing script while the prompt was a quiz. Navigation scores 1 even if the script is technically neat. The repair is to map the prompt onto the seven moves in the first six minutes, using the prompt's nouns.

The locked dive. The interviewer says "talk about retention," and the candidate stays on the matching algorithm. It happens because the matching story was practiced more. The consequence is a missed probe and a lower navigation score. The repair is to write the second dive's name on the board at minute thirty-three so switching is a physical move, not a loss of face.

Troubleshooting and Design Review

Use this table when you review a practice recording or a debrief that feels vague.

A design review of an interview is not a design review of a production system. Lesson 69's checklist is for the latter. Here you are reviewing the performance of the framework. Two questions are enough to start: which artifact is missing, and which rubric row has no quote under it?

When you are the interviewer, write the quote during the loop, not after. Memory flatters confident speakers. The form should contain the conditional update or it should contain a blank. Blank is a 1 or a 2. It is not a 3 with a note that says "seemed senior."

Interview Questions and Answers

Q1. What is a system-design interview actually scoring?

It scores four signals: whether you narrow an ambiguous prompt, whether the mechanism you choose enforces the invariant you named, whether you can reject an alternative and say when you would reopen it, and whether another engineer can reconstruct the design from what you said. It does not score operational heroics, brand familiarity, or drawing style. TechLearningPro's rubric turns those signals into six weighted rows: navigation, estimation, API and data, high-level design, deep dive, and trade-offs. A weighted 3.0 is a solid senior pass. A brilliant deep dive with no scope sentence stays a risky hire because the panel cannot tell whether you solved the prompt.

Q2. Why is the order clarify, then estimate, then API, then data, then diagram?

Each move deletes options. Clarifying "one metro" deletes a global sharding lecture. The estimate deletes a second trip database when creates are tens per second and points you at location ingest. The API deletes boxes that no caller uses. Data ownership deletes a second writer before the diagram tempts you to add one. If you draw first, every later discovery forces an erase, and the clock is spent on redrawing. The order is the same as lesson 23 because both are design. The interview adds a minute budget and permission to leave a reopen condition instead of a finished subsystem.

Q3. How do you estimate when the interviewer gives you no numbers?

You publish assumptions and mark them as yours. Pick a concrete population, a daily or burst volume, a peak factor, and a record size. Compute one rate and one storage figure with units. End with the resource that saturates first. Invite a correction: "If the metro is ten times larger, location ingest is still the hot path until this threshold." The interviewer will often change one input. Recompute only that input's dependents. An estimate you will not let anyone edit is a script. An estimate with a blank assumption column is a guess. The middle is the scored skill.

Q4. What belongs in an interview API, and what should you leave out?

Include the caller, the retry rule, the success status, and the failure the user can see, for three to five operations. Unsafe creates get an Idempotency-Key whose replay rules you can say in a sentence. Illegal state transitions get 409. A down dependency on a required path gets 503 or an explicit unknown state you reconcile. Leave out SDK catalogs, graphical API browsers, and every list endpoint. Mention cursor pagination only if a list is in scope. The contract is there so the deep dive has a method to attach to. A diagram with no operations leaves the double-click probe homeless.

Q5. How do you choose the deep dive when several boxes are interesting?

Choose the box where a wrong mechanism breaks the product invariant, then offer one alternative so the interviewer can steer. For Dispatch, match and double-accept outrank the shape of a push notification. For exam intake, the unique open attempt and the submit transition outrank the draft-save cache. Announce the bug you are preventing before the mechanism. If you cannot name the bug, you are not ready to dive, and you should step back to data ownership. Stay at one level of depth: structure, concurrency, one failure, one test. A second subsystem in the same dive is a new move you were not offered.

Q6. What is a good answer to "it depends"?

A decision, the option refused, the cost of the decision, and the measurement that reopens it. "It depends on scale" is incomplete until you use the number you already wrote down. "We keep trips on one primary because peak creates are about thirty per second. We split location ingest because that path is about five thousand writes per second. We reopen trip sharding when a second metro must fail independently or when trip writes exceed a primary's measured headroom." That answer scores the trade-off row. A table of pros and cons with no circle around a choice scores as a 2.

Q7. How does a staff-level loop differ from a senior loop under this framework?

The seven moves and the weights stay. The prompt usually includes a system that already runs. The trade-off move grows a migration slice: what the system of record is during the change, how a single venue or tenant rolls back, and who is paged. The deep dive often includes compatibility, such as a reader that must understand old and new trip states. A staff candidate who ignores the existing spreadsheet and designs a green-field planet has treated a staff prompt as a senior prompt. A senior candidate who spends ten minutes on an org chart has spent staff time they were not given. Lesson 61 is the judgment. This lesson is the clock that keeps that judgment short enough to fit.

Q8. How should you recover when you realize your design is wrong with ten minutes left?

Say the invariant you failed to protect, in one sentence. Name the smallest change that protects it. Apply that change to the API status and the owner. Do not redraw unrelated boxes. Example: you allowed two accepts, you have ten minutes, you add a conditional update and a 409, and you drop the speech about a new cache. Panels score the recovery under navigation and deep dive. A quiet erase of the board reads as panic. A narrated correction reads as seniority. If the clock is inside the last three minutes, state the correction and the test you would run, and go to the trade-off. An unspoken fix does not exist in the debrief.

Q9. How do you talk about consistency without reciting a theorem?

Name the invariant in product language, the single place it is enforced, and what a caller observes if they lose the race. "A driver has one in-progress trip, enforced by a conditional update in the trip database. The losing accept gets 409 and the trip still has one winner." Add a consistency label only if it helps: the trip row is linearizable at the primary; the nearby-driver list is a derived view that can be a few seconds old, and staleness there causes a wasted accept attempt, not two winners. Lesson 31 is the background. The interview wants the invariant and the user-visible race. A theorem with no row-level mechanism scores as a recitation.

Q10. How do two interviewers calibrate with the rubric?

They quote mechanisms, not adjectives. Before the debrief they each fill the six rows from their notes. A row with no quote is a 1 or a 2, agreed in advance. They compare quotes, not feelings. A one-point gap on a row is resolved by reading the quote aloud. Weights are fixed so a deep-dive enthusiast cannot outvote a missing scope sentence. The worked Dispatch loop in this lesson is a calibration recording: both reviewers should land near 3.5 if they heard the conditional update, the location bottleneck, and the reopen condition. If one reviewer scores that recording as a 2 because "they did not mention Kubernetes," the reviewer is scoring a poster the rubric does not contain. Fix the reviewer. Do not add Kubernetes to the candidate instructions.

Q11. Where do security and privacy fit in a forty-five-minute loop?

Inside clarify, as a constraint: what you will not store, and who may call each operation. Inside the diagram, as a trust boundary around caller-supplied locations, URLs, or tokens. Inside the deep dive, only if the bug is a security bug, such as an open redirect or a tenant predicate. A full threat model is lesson 63 and does not fit the clock. One sentence does fit: "Location history is retained seven days, accessible to a safety role, and match uses only the latest point." If the prompt is payments, the sentence is "the provider holds card data; we store a charge id and an idempotency key." Saying nothing about data sensitivity on a location or payment prompt leaves the API-and-data row short of a 4 and sometimes short of a 3.

Q12. How do you practice so the framework survives a new prompt?

Run the clock on two prompts a week, from different domains, with a timer and a blank page. The next day, score only from the page, using the rubric, and write the missing artifact at the top. Keep a list of your repeated misses. If it says "no bottleneck sentence" three weeks in a row, the practice goal is that sentence, not a new prompt. Once a month, ask a colleague to change one assumption at minute twenty. The skill you are building is recomputation, not a Dispatch script. Lesson 67 and lesson 68 are structured versions of this drill for low-level and high-level prompts. The capstone in lesson 70 removes the clock and asks for the full packet. Candidates who can only perform under one of those two pressures are half-trained.

Hands-On Exercises

Exercise 1: timed Dispatch loop

Problem. Run a forty-five-minute mock of "design ride booking for one metro." Use a colleague or a recording. The interviewer must change one assumption at minute fifteen: either 50,000 active drivers or payments out of scope entirely.

Tasks.

1. Produce the four lists: behavior, quality, constraints, assumptions.
2. Compute trip-create rate, location-write rate, and seven-day retention from your assumptions.
3. Write five operations with status codes and an idempotency rule.
4. Name the single writer of trip status.
5. Draw the boxes and the trust boundary.
6. Deep-dive the accept transaction, including the losing caller.
7. Close with decision, refusal, cost, and reopen condition.
8. Score yourself the next day with the weighted rubric. Quote the board under each row.

Done when. A second person can find the bottleneck sentence and the conditional update without asking you what you meant. Your weighted score is computed, not vibed.

Exercise 2: exam-window quiz, sixty minutes

Problem. Design quiz attempt intake for 40,000 learners, using the scenario in this lesson. You have sixty minutes, so take the second deep dive: the final-minute submit cliff and how you shed load if the primary crosses a limit you state.

Tasks.

1. Separate the begin spike from the submit cliff in the estimate.
2. Specify unique-open-attempt and idempotent submit.
3. State what draft autosave is allowed to lose.
4. Name the tenant predicate on the attempt row.
5. Describe one load-shedding behavior that preserves already-open attempts.
6. Score navigation and estimation with particular honesty. Those are the rows this prompt punishes.

Done when. The reopen condition says what submit rate would force object storage or a queue, and what the learner sees while a submit is queued.

Evaluation rubric

Use the six-row rubric in this lesson. For these exercises the weights stay as published: navigation 15, estimation 15, API and data 20, high-level design 15, deep dive 25, trade-offs 10. A complete submission includes the quotes. A submission that includes only a diagram is capped at 2 on every row except high-level design.

Lesson Summary

A system-design interview is lesson 23's sequence on a clock: clarify, estimate, API, data, high-level design, one deep dive, and a decision with a reopen condition. The artifacts are a scope sentence, a labeled bottleneck, a retryable contract, a single writer, a small diagram, a mechanism that protects an invariant, and a trade-off you could drop into an ADR. TechLearningPro scores those artifacts on six weighted rows. A weighted 3.0 is a solid senior signal. Staff loops keep the rubric and add a migration slice.

The Dispatch walkthrough shows the cut that fits in forty-five minutes: location ingest is the hot path, trip create is not, accept is a conditional update, card data stays at the provider, and sharding waits for a measurement. The exam-window scenario shows the same framework on a burst that is not a ride. Memorizing one prompt fails the other. Practicing the clock, then scoring the page the next day, is the work.

Lesson 67 takes the deep dive down to interfaces, concurrency, and tests under a similar clock. Lesson 68 runs the high-level clock on the URL shortener, the feed, and payments. Lesson 69 reviews the packet you would write if the interview became a real design. The capstone removes the timer and asks for all of it.

Further Reading

• RFC 9110, HTTP Semantics — status codes used in the interview contract, including 409 and 503.
• RFC 6585 — 429 Too Many Requests, the limiter response named in the API move.
• Architecture decision records — the shape of the closing trade-off, in long form.
• C4 model — container-level boxes when the interview diagram needs a second level of care.
• AWS Well-Architected Framework — a review lens for the reopen condition, not a box to draw in minute five.
• Google SRE book, Embracing Risk — why an availability sentence belongs in clarify even when you will not build an error budget in the room.
• PostgreSQL UPDATE — conditional updates as the linearization point in the accept dive.
• Lesson 23, lesson 24, lesson 53, and lesson 37 in this course — the method, the arithmetic, the Dispatch packet, and idempotency, which this hour compresses and does not replace.