Queues instead of synchronous processing outside the critical path
Side effects outside the critical response path run asynchronously via a queue. The request acknowledges quickly; processing happens idempotently in the worker.
What is this? · Decision Record
A documented architecture decision in ADR format — context, options considered, rationale and consequences. One concrete decision, not a general guide. Go to overview
- Status
- Accepted
- Identifier
- ADR-002
- Review
- To be revisited when latency or consistency requirements change.
Context
Many operations trigger side effects — notifications, exports, calls to third-party systems, recalculations. Whether these run synchronously in the request or asynchronously via a queue shapes latency and resilience.
Problem
Synchronous side effects tie the response time to the slowest system involved and cause a request to fail when a side effect fails. Asynchronous processing decouples, but it brings eventual consistency and delivery semantics with it.
What we considered.
- A
Synchronous in the request
Simple — but latency and failures are coupled to the side effect.
- B
Asynchronous via a queue
Decoupled and more resilient — requires idempotency and monitoring.
- C
Fire-and-forget
No backpressure, no retries, no proof of delivery.
What we decided.
Side effects outside the critical response path run asynchronously via a queue. The request acknowledges quickly; processing happens idempotently in the worker.
Why this decision
The queue decouples response time from slow or unreliable side effects and makes retries and backpressure explicit. Idempotency ensures that at-least-once delivery doesn't produce duplicate effects. Whatever is critical for the response stays synchronous.
Consequences
- The system becomes eventually consistent for the offloaded effects; the user interface has to account for that.
- The queue, workers and failed jobs must be visible.
- Every asynchronous operation must be designed to be idempotent.
Rejected alternatives
- Everything synchronousCouples latency and failures to the slowest side effect.
- Fire-and-forgetWithout retries and proof of delivery, effects are silently lost.
Continue your engineering journey.
Related concepts, decisions, playbooks and perspectives — as one connected path, not a list of links.
Technologies
Facing a similar decision?
We don't make it on gut feeling. Talk to our management — technical, no sales pitch.
