Why some work should leave the request path and happen later.
Which part of checkout must finish before the user gets a response, and which part can happen later?
Before reading, list one task that belongs on the request path and one task that should leave it.
Async thinking returns in video processing, notifications, analytics, feeds, and write-heavy systems.
If one user action also sends email, generates thumbnails, writes analytics, triggers notifications, and calls three slow services, the clean move is usually not "do it all now."
The more side work you keep inline with the request, the more fragile the user-facing path becomes. A good design usually finishes the essential user action first, then hands the rest to background systems that can retry, buffer, and scale separately.
The strong answer starts with the product and the critical path, then chooses the delivery model.
A worker picks up a task, times out while writing, and retries. The system may now process the same message twice.
That is why idempotency matters. Good background processing assumes retries will happen. The real design question is whether running the task twice causes harm. If it does, you need idempotency keys, deduplication, or carefully structured writes.
Queues and streams are added when the system needs to sound scalable.
Async processing is for work that is slow, retryable, bursty, or not required for the immediate user response.
Draw the user path first, then move side effects behind a queue with retry and idempotency.
| Processing choice | Good when | Weak when | Interview line |
|---|---|---|---|
| Fully synchronous | The user must know the outcome immediately and the work is small enough to keep inline. | Side work is slow, bursty, or failure-prone and makes the request path fragile. | I would keep only the truly user-critical work synchronous. |
| Queue + workers Default | One task should be processed later, with retries and buffering. | Several independent systems need the same event for different reasons. | A queue fits because the main need is durable task handoff to workers. |
| Stream + consumers | One event should be consumed by several downstream systems independently. | You only need a simple handoff and do not benefit from broader fan-out. | A stream fits when the same event should feed several consumers without tight coupling. |
| Async everywhere | Most side work is naturally decoupled and delay is acceptable. | The product needs immediate consistency or confirmation for that work. | I would only move this off-path if the product can tolerate eventual completion. |
Do not jump straight from reading to a full answer. First see the shape, then complete part of it, then answer alone.
I would keep payment authorization on the critical path, then queue email receipts, inventory sync, and analytics.
For checkout, classify each task as blocking, async, or batchable.
Answer the practice prompt and explicitly say what leaves the request path.
Before moving on, turn recognition into production. Close the model answer, answer from memory, then retry one small slice.
Say the chapter's core idea without looking. Then name one related idea from an earlier chapter.
Change one constraint in the practice prompt and answer again in half the time.
Use the rubric to pick one dimension below 3, then retry only that dimension.
Do the essential user-facing work first and return.
That distinction is enough for most interviews.
Idempotency is the adult answer.