Explain a System You Built, Then Convert a Synchronous Request to Asynchronous

In a system design round on a shared online whiteboard, the interviewer first asks you to draw the architecture of a complex system you have worked on and explain it. You then add a new feature to that system in the same style. The example the interviewer gave is to change a synchronous request into an asynchronous one, and to discuss the advantages and disadvantages of doing so. The report does not name the system or the request. If you need a concrete case for Part 2, assume an HTTP endpoint that, inside the request, calls a slow downstream dependency (such as a third-party service or a heavy computation) and responds only when that work has finished, so callers sometimes wait many seconds or time out. ### Clarifying Questions - For Part 1, how much detail is expected: the main components only, or also data models and request flows? - For Part 2, may you choose which request to make asynchronous, or does the interviewer have one in mind? ### Part 1 — Explain a system you built Draw the architecture of a complex system you have worked on and walk the interviewer through it. ```hint Follow one request Pick one important request and trace it through every component you draw, so the diagram explains behaviour rather than listing boxes. ``` #### What This Part Should Cover - The system's purpose, scale and main components, how they communicate, and where data lives - One request traced end to end, including what happens when a dependency fails - Your own role, and the design decisions you made or would revisit ### Part 2 — Make a synchronous request asynchronous Pick a synchronous request in that system, or use the assumed endpoint above, and redesign it so the work is processed asynchronously. Explain the new flow and the advantages and disadvantages of the change. ```hint What the caller gets now Decide what the caller receives immediately, how it later learns the outcome, and what the work needs in order to stay correct once it is no longer tied to the caller's open request. ``` #### Clarifying Questions for this Part - Does the caller need the result before it can continue (for example, to show a confirmation), or only an acknowledgement that the work will happen? - Who calls the endpoint: browsers, mobile apps or other services, and can they receive callbacks? - How long does the slow step take, how often does it fail, and is it safe to repeat? #### What This Part Should Cover - The new flow: acceptance, queueing, workers, job status and delivery of the result - Correctness under at-least-once delivery: idempotency, retries, failure states, and writing the job and its queue message consistently - Advantages and disadvantages compared with the synchronous version, and when to keep it synchronous ### What a Strong Answer Covers - A clear, honest account of a real system, with trade-offs the candidate can defend - Clarifies what the caller needs from the response before changing the interaction model - An asynchronous design with durable job state, a queue, idempotent workers and a defined way to return results - Failure handling: retries with backoff, a dead-letter path, and how the caller learns about a permanent failure - Capacity and observability: backlog growth, worker scaling, protection of the downstream dependency, and the metrics that show health - A balanced comparison: latency and resilience gained versus complexity and eventual consistency ### Follow-up Questions - The queue delivers a message twice and the downstream call is not idempotent. What breaks, and how do you prevent it? - A job fails permanently after the caller was told it was accepted. How does the caller find out, and what happens to the job? - Traffic triples during a peak. Where does the asynchronous design absorb the load, and what new risk does a growing backlog bring? - Existing clients expect the synchronous response. How do you migrate them without breaking them?