Handling slow work asynchronously
40 min · Intermediate
An asynchronous API accepts a slow request, answers at once with a ticket (a job id), and does the work in the background. The client then checks the job's status or is told when it is done, instead of holding a connection open for minutes.
Topics in this lesson
- Slow work that does not fit in one request
- 202 Accepted, a job id and a status endpoint
- Webhooks: the server calls you back
- Simulation: ExecutorService runs the job, the client polls
- Job states and storing results for download
Key points
- Work that takes more than a few seconds, or near proxy limits, belongs in an asynchronous API.
- Answer 202 Accepted with a job id and a status URL; clients poll GET /jobs/{id} until DONE or FAILED.
- Webhooks call the client back when done; they need retries, signatures and idempotent receivers, with polling as the fallback.
- Jobs move PENDING → RUNNING → DONE or FAILED; results go to storage with an expiring download link.
Interview questions this lesson answers
- How would you design an API for a report that takes two minutes to build?
- Polling or webhooks?
- What states would a background job have?
- Where would you keep job status when there are several app servers?
- How would you run background jobs in plain Java?
- How do clients download the result, and for how long?
Sign in to continue this lesson
Create an account to read every lesson, practise with the exercises and keep track of your progress.