If you’ve ever built an endpoint that takes more than a few seconds to respond, (video processing, large data imports, AI inference) you’ve probably hit the problem Async APIs are designed to solve.
Let’s walk through how they actually work 👇
The problem: long-running requests
A normal (synchronous) API expects you to return a result immediately.
But what if the operation takes minutes?
Say a client asks your server to:
Search through 10k YouTube videos,
Read a few thousand emails,
Or generate a large ML model result.
If your server holds the HTTP connection open, you’ll likely hit timeouts, retries, and blocked resources. That’s where async APIs come in.
Step 1: Accept the request, fast
When the client sends the request, the API doesn’t do the heavy work right away.
Instead, it immediately returns 202 Accepted response:
You’ve acknowledged the request, but haven’t completed it yet.
This means the client doesn’t block. The server can instantly move on to handle new requests while background workers process tasks at their own pace.
Step 2: Process asynchronously
Workers pick jobs off the queue, one by one.
Each worker performs the slow operation — video analysis, report generation, etc. — and then writes the result to a database, where you can easily look it up later with the associated JobID.
Step 3: Return the data to the client
Once the processing is complete and finalized data is in the database, you can either:
Notify the client via some mechanism, ie SSE
Let the client poll an endpoint like
/jobs/12345/status.
Why this pattern matters
Async APIs are the foundation of:
AI model inference services (OpenAI, Anthropic)
Cloud rendering pipelines (Figma, Adobe)
Data-heavy batch systems (Stripe exports, AWS Glue)
They make systems more reliable under load by decoupling requests from execution.
See you next week,
– Arjay
PS. If you like Queues, my YouTube video this week goes into a few more cool use cases. It’s a quick watch.