The final design interview

01Pick a prompt and reset the page

The final rehearsal checks whether another person can follow your design from a blank page. Choose a studied case, close its answer, then record yourself or ask a partner to interview you. Change one important constraint so you must reason again: add private data, a second region, ten times the peak, or a payment response lost after the customer may have been charged.

Use this prompt when practising alone:

Design concert booking. Customers browse seats, hold their complete selected seat group for two minutes, pay, and recover booking status after a timeout.

Clarify the promises before drawing:

1. Must a two-seat request receive both seats or neither? Assume yes: no partial group.
2. When does the customer become the confirmed owner, and what happens while payment is uncertain?
3. Which payment methods can query or safely repeat an earlier operation?

The central correctness rule is at most one confirmed booking owner for each event-seat.

Prepare the same seven areas used in the course:

1. Requirements: functions, measurable service targets, exclusions and rules that must always hold.
2. Estimates: traffic and bytes, assumptions and units, plus what each important result changes.
3. API: requests, responses, errors and recovery after timeout.
4. Data model: stored records and keys, who changes them, and which changes must commit together.
5. High-level design: complete read/write paths, including the records saved before success.
6. Deep dive: the hard mechanism or bottleneck, alternatives, one justified change and its cost.
7. Failure review: races, timeouts, permissions, accepted tradeoffs and the next test.

Write assumptions where your partner can challenge them. A component name is not evidence that an operation works; a calculation or trace must explain it.

02Spend 45 minutes deliberately

Use this 45-minute sequence, adapting when the interviewer deliberately explores one hard operation:

Build a compact concert baseline

1. Browse: GET /events/E1/seats returns a timestamped cached seat map for event E1. It can show an older available seat; it cannot grant that seat.
2. Request a group: POST /events/E1/holds carries seats [A7,A8] and one request key. The reservation service checks and claims the whole group in one transaction, then returns hold H1 and its deadline.
3. Save the records: a Seat row is keyed by event and seat; a Hold row links H1 to the account and complete group. A request-result row maps the account/key to the submitted fields and original H1 result.
4. Recover the hold: repeating its key with matching fields returns H1 and the original deadline; it does not restart the two minutes.
5. Begin checkout: the client sends a separate request key that it will keep for retries. In one transaction, verify that H1 belongs to this account, still holds the complete seat group and has not expired at the time of the check. Save booking B1, that checkout key and a pending provider-operation ID; change the seats to payment-pending before contacting the provider.
6. Recover checkout: if its response is lost, repeat the checkout key to retrieve B1, then call GET /bookings/B1. This recovers an ID from saved state rather than requiring one that appeared only in the missing response.

At 100,000 browse requests/s and 50 KB per map, payload is 5 GB/s. Caching can reduce repeated origin work, though those bytes still reach viewers. If tests show the writer safely handles 2,000 holds/s, limit excess launch attempts; that test does not prove seat correctness.

Trace the baseline first. Add a waiting room to control excess work and explicit payment states to resolve uncertain charges only where those requirements justify them.

03Score visible reasoning, not component count

After the mock, score what another person can actually find in the recording or page. These are practice weights, not an employer's policy.

Suppose the score is 12+8+10+14+10+6+8 = 68. The drawing is readable, but a hold can acquire only half the requested group and a payment retry creates a fresh charge ID.

Use the score this way:

1. Name the failed promises. Complete groups are not enforced, and response loss may create two charges.
2. Repair those operations first. Show the all-or-nothing seat transaction and recovery of the original payment operation.
3. Score the new explanation. Award credit for demonstrated behavior, not for adding a box or the word “idempotent.”

For partial credit, state the missing piece precisely: “The API accepts a retry key but saves no result for that key,” or “The storage calculation excludes replicas.” “Needs depth” does not tell the learner what to fix.

A high total cannot excuse two owners for one seat. Also distinguish a feature explicitly excluded during requirements from a required feature silently omitted to simplify the answer.

04Inject failures and follow the state

Use two customers, Mina and Leo, to test the actual seat records. Both initially see A7 available; Mina requests A7 and A8 together.

1. Mina's reservation transaction locks both seat rows before checking them. Each must be free, or held under an ordinary hold whose deadline has passed at the database’s check time. A seat in payment-pending or confirmed state is not free merely because two minutes elapsed.
2. If both are available, save H1 and both claims with the request result. If A8 is unavailable, roll back the complete group; Mina receives neither seat.
3. Leo’s competing A7 request locks and checks the same saved row. After Mina commits H1, the row points to her unexpired hold, so Leo is rejected. His earlier available-seat display cannot override that row.
4. Lose Mina's success response. A repeated request key finds H1's saved result and returns its original deadline. A retry must not silently create a new two-minute hold.
5. Time out a payment that may have charged her. The client repeats its saved checkout key to recover booking B1. The service queries the provider using the original payment operation ID retained with that booking. Absence of a response does not establish payment failure.
6. The checkout transaction changes the held seats to payment-pending. The ordinary hold-expiry cleanup must now leave them reserved while the recovery worker queries the saved provider operation. Confirm ownership only after payment success is known and the booking/seat records commit that outcome together; a definitive payment failure can release them. This can keep seats unavailable during a provider outage. If an exceptional recovery has already released them and a late charge succeeds, save refund-required state instead of granting a seat now promised to someone else.

Test other cases with equally concrete questions

For every failure, answer four questions

1. Which record survives the crash?
2. Which state change is allowed next?
3. How does a retry identify and recover the original attempt?
4. What does the caller see now?

A queue can save pending work. It does not by itself answer whether the business effect happened, which state is current or whether repeating that effect is safe.

05Make the next two hours count

Use the remaining practice time to repair the most consequential gap, then explain it without the answer page.

For the 68-point concert mock

1. Write the seat transaction as three steps: protect the whole group, check every current seat, then save all claims and the result together or none.
2. Write the payment-pending transition: checkout verifies the complete unexpired hold and saves the booking, checkout key and provider-operation ID together before contacting the provider.
3. Write the payment outcomes: known payment success permits an atomic booking/seat confirmation; definitive failure permits seat release. A timeout remains pending while the saved provider operation is queried.
4. Write the late-charge recovery: if paid inventory can no longer be granted, save refund-required state and arrange the refund; do not create a second owner.
5. Replay Mina and Leo’s race and the lost response. Point to the record that makes the wrong outcome fail.
6. Score only what is now demonstrated. A key without a saved key-to-result lookup still does not explain safe retry.

Choose other repairs in the same concrete way

• Recalculate a wrong estimate with units and identify the choice it changes.
• Replace “ensure consistency” with the actual conditional update or transaction.
• Replace an unclear diagram with one numbered request path and labeled results.
• After a missed quiz question, revisit its linked section and solve a changed example before trying the same question again.

Near the interview, use the revision deck for a 60-, 90- or 120-minute whole-course pass. Select all topics, attempt each answer before revealing it and mark “Again” when you recognize a term but cannot explain its operation. Recognition of a repeated option is weaker evidence than an independent explanation later.

Close the mock in four connected sentences

We support browsing, complete seat holds, checkout and booking recovery. A cached map serves browsing; a database transaction checks and reserves the complete group. The map may briefly show a taken seat as available, but only the reservation transaction grants it. Next I would test many buyers competing for the same seats and recovery after an uncertain payment.

That close names the agreed functions, working path, accepted tradeoff and next validation without claiming unmeasured production performance.