When should an API use a message queue instead of a synchronous call?
Quick Answer
Use a queue when the work is slow, can be done later, must not be lost if a downstream is down, or needs to be retried/rate-limited independently — sending emails, generating reports, syncing to another system. The API accepts the request, enqueues a message, returns 202 Accepted, and a background worker processes it.
I reach for a queue when the work doesn't have to finish before I respond, or when losing it would be bad. Sending a confirmation email, generating a big report, pushing data to another system — the API validates the request, drops a message on the queue, returns 202 Accepted, and a worker handles it. That way a spike in traffic just fills the queue instead of overwhelming the database, and if the downstream is down the message waits and retries. The pattern I always mention alongside this is the outbox — writing the business change and the message in one transaction so they can't get out of sync.
- Synchronous when the caller needs the result now and the operation is fast and reliable (a lookup, a simple create).
- Asynchronous / queue for: long-running work, buffering load spikes, decoupling from a flaky downstream, fan-out to multiple consumers, guaranteed delivery with retries and a dead-letter queue.
- Return
202with a status URL the client can poll, or notify via webhook/SignalR. - Consistency: use the outbox pattern — write the domain change and the outgoing message in the same DB transaction, then a relay publishes it — so you never lose or double-send a message.