Message queues and event-driven work
The difference between an order that quietly fails and one that retries until it succeeds is usually a queue.
Messaging
Chosen per project
Maintainable handover
Plenty of work does not belong in the request that triggered it. Generating a PDF, pushing an invoice to an accounting system, sending a batch of messages — do it inline and the user waits, and a failure anywhere in the chain loses the work.
A queue makes the work durable. The request finishes immediately, the task is recorded, and a worker picks it up — retrying on failure, and parking anything that cannot succeed where a human can see it rather than silently discarding it.
What we build with Message queues
Integrations with third-party systems that are slow or occasionally down
Bulk operations — statements, notifications, imports, report generation
Smoothing traffic spikes so the database is not hit all at once
Passing events between services without them calling each other directly
Where it fits — and where it does not
Good fit when
Work that must not be lost if a process restarts
Anything that depends on a system you do not control
Slow tasks that currently make a user wait
Consider something else when
Work whose result the user needs on the same screen, immediately
Very small systems where a database-backed job table is simpler
What happens to a job that fails
The point of a queue is that the unhappy path is designed rather than accidental.
Published
Request returns immediately; work is durable.
Consumed
A worker takes the message with a visibility timeout.
Retried
Transient failure? Redelivered on a backoff schedule.
Dead-lettered
Still failing? Parked, alerted, inspectable.
How we work with Message queues
Idempotent handlers
Every consumer is written so processing the same message twice is harmless — because eventually it will happen.
Retry with backoff
Transient failures retried on a widening delay rather than hammering a system that is already struggling.
Dead-letter queues
Messages that cannot be processed are parked and alerted on, never dropped.
Visible depth
Queue length and consumer lag are monitored, so a backlog is noticed before customers notice it.
Our typical Message queues setup
| Concern | What we use |
|---|---|
| Brokers | RabbitMQ, Azure Service Bus, Amazon SQS, Kafka where ordering and replay matter |
| Delivery | At-least-once, with idempotent consumers to make that safe |
| Poison messages | Dead-letter queue with alerting and a replay path |
| Scheduling | Delayed and recurring jobs where the broker supports them |
| Monitoring | Queue depth, age of oldest message, consumer lag |
Frequently asked questions
For modest volumes a jobs table with a worker process is genuinely simpler and easier to debug. A broker earns its place when you need fan-out to several consumers, ordering guarantees, or throughput a database polling loop cannot sustain.
Nothing, if the handler is written to be idempotent — which is how we write them. Duplicate delivery is normal in every at-least-once system, so it is designed for rather than hoped against.
Yes. Failed messages land in a dead-letter queue with the original payload and the error, so they can be inspected, fixed and replayed instead of vanishing.
Topics people search for
Services built with Message queues
API Development
The interfaces that let your systems talk to each other, and let partners build on top of what you have.
Custom Software Development
Software shaped around the way your business already works, instead of a packaged product you have to reorganise around.
Enterprise Software Development
Systems for organisations where several departments, sites and approval chains all have to work from the same data.
Cloud Solutions
Hosting designed around what your application actually needs, with the monitoring and backups that make it safe to rely on.
Tell us what you are trying to build
Describe the problem in plain language and we will tell you what it would take to solve it — the approach, the moving parts and the sensible order to build them in. No obligation either way.