A repeatable interview process

01Use a route through the problem

Lina wants to send Omar “Meet at six.” Omar may be offline, so the service must save the message for a later history read. Use seven questions to build the design:

1. Clarify requirements. Agree on sending, history and live updates. Define what “sent” means and which features are excluded.
2. Estimate important load. Calculate the requests or bytes that affect the next decision.
3. Define the API. Show what Lina sends, what success returns, and how errors and repeats behave. API means application programming interface: the way callers use the service.
4. Define saved records. Show messages, conversation membership and saved request outcomes, including how requests find them. This is the data model.
5. Draw the first complete design. Trace a send and a later read through the smallest working set of components.
6. Investigate the main risk. Show one difficult mechanism or bottleneck and a justified change.
7. Review failures and costs. Check the original promises after a race, timeout or missing dependency; name the next validation.

For a 45-minute practice, allocate 5 minutes to requirements; 3 each to estimates, API and records; 8 to the first design; 18 to the main risk; and 5 to review. These are practice allocations. If the interviewer asks about ordering early, address it and keep the other unanswered questions visible.

For this example, assume “sent” means safely accepted into history. It does not mean Omar has read it. Group calls are outside the exercise.

02Move from the message to a working design

First calculate the assumed send load:

1. One million active people ×20 messages/day =20 million sends/day.
2. Divide 20 million by 86,400 seconds/day ≈231 sends/second on average.
3. Apply an assumed fivefold peak: about 1,160 sends/second.

This estimates requests, not machine capacity. The service still has to check membership, save each message and deliver updates to recipients.

For the API, Lina supplies the conversation, text and an identifier for this intended send. Call that request r44. In this example the conversation is c9.

The service handles it as follows:

1. Verify Lina’s identity and current membership in c9.
2. Begin a database transaction and check whether Lina’s request r44 already has a result.
3. If it does, compare the submitted intent with the saved one. Return the same result for a matching repeat; reject reuse with different text or conversation.
4. If it does not, save the message and the r44 result together. The database must enforce uniqueness for Lina’s request identifier, so two simultaneous repeats cannot both insert a message.
5. Commit those changes together, then return the result. Call the saved message m82, at position 82 in this conversation.
6. Notify Omar if he is connected. That notification can be retried independently of saving history.

The API returns m82 and its position. The data model stores the message, membership and request-to-result record used by these steps. The transaction makes the message and its retry record complete together or not at all.

Omar later requests messages after position 81. The service checks his membership and returns later saved positions in order. His last applied position is a cursor, a marker saying where to continue.

03Use failure to choose the deep dive

Lose the response after the transaction commits. Lina cannot tell whether the send succeeded. Follow recovery through saved data:

1. Lina repeats request r44, rather than creating a fresh request identifier.
2. The service finds the saved mapping from r44 to m82.
3. It returns m82. It does not append a second message.
4. Omar can still read position 82 from history even if its notification was lost.

Choose a deeper investigation from the actual risk:

• If two sends arrive together, explain how the service assigns distinct positions within one conversation.
• If Omar reconnects after ten minutes, show the history range requested after his saved cursor.
• If one conversation receives most traffic, identify the machine handling it and measure whether that machine can keep up.
• If several devices maintain read positions, define which cursor belongs to each device or account.

For each investigation, show the record before the operation, the checked condition, the saved change and the caller’s result. A box labeled queue or database does not explain these decisions.

Finish by checking the agreed behavior:

• Every send and history read checks membership.
• A successful send has the required saved history.
• A repeated send retrieves its original result.
• A disconnected reader has a history path to recover.

State unresolved work explicitly, such as multi-device cursors, and choose a measurement such as the oldest undelivered message. That identifies what to investigate next.