A webhook and event bus layer
that does not lose a message when a service restarts
Most webhook problems are not about receiving an event. They are about what happens next: delivery fails halfway through, a service goes down, a duplicate arrives twice, a payload changes shape. We build the event bus layer that handles those cases by design, not as an afterthought after the first production incident.
The difference between a webhook and an event bus
A webhook is a single HTTP request a provider sends you when something happens: a payment clears, an order ships, a message arrives. An event bus is what you build once more than one internal service needs to react to that same event.
Without one, a webhook handler ends up calling three other services directly. If one of them is slow, the whole chain breaks in a confusing way. With an event bus, the handler publishes the event once. Each consumer picks it up independently, at its own pace, with its own retry logic.
When one webhook handler is not enough
You need this once a single handler has grown branches: if this is a payment event, update the CRM, send a Telegram alert, update the warehouse. That pattern fails the way you would expect. One slow or down dependency blocks or breaks the whole chain. A partial failure leaves data inconsistent across systems, with no record of what actually happened.
You also need it if a provider’s webhooks arrive out of order or get delivered twice. That is normal behavior on their end, not a bug, and most handlers are not built to expect it.
You do not need a full event bus for a single webhook feeding a single downstream action. That is just a receiver with retry logic, a smaller and cheaper build. An event bus earns its cost once two or three consumers need the same events independently.
The stack we actually use, and why
For most clients we start with Redis Streams. It handles the common case well: several consumers, replay, consumer groups, all without the overhead of running a dedicated message broker. For higher volume, or where delivery guarantees matter more than simplicity, we use RabbitMQ or a managed broker instead.
Every incoming webhook gets signature verification against the provider’s documented method first. Nothing gets processed from a request we cannot prove came from who it claims. An idempotency key, usually the provider’s own event ID, stops a retried delivery from double-processing.
Events that fail after a set number of retries move to a dead-letter queue instead of disappearing. We log enough context to debug them without replaying the whole stream.
We built exactly this kind of event layer underneath a digital goods marketplace. One purchase event there has to trigger delivery, notification and accounting updates, each on its own.
Where this can quietly go wrong
The main cost of an event bus is operational, not financial. It is another piece of infrastructure to monitor. A queue that silently backs up is worse than a webhook that fails loudly, because nothing looks broken until a consumer is hours behind. That is why we build monitoring on queue depth and consumer lag into the initial setup, not as a later add-on.
Vendor lock-in is low for Redis Streams and RabbitMQ. Both are open source and self-hostable. A managed broker service does tie you to that provider’s pricing and API, and we flag that tradeoff before choosing it.
The other real risk is event schema drift: a provider changes a payload’s shape without warning. It is the same problem our API integration work handles, and we apply the same alerting here.
We also separate event types that are safe to replay from ones that are not. Replaying a payment-confirmed event twice is harmless if consumers are idempotent. Replaying a stock-decrement event carelessly can double-count inventory. Replay tooling needs the same care as the original delivery path.
Two ways to scope this
| Scope | Price | Timeline |
|---|---|---|
| Single webhook, retries and dead-letter queue | from $1,500 | 1 to 2 weeks |
| Event bus, multiple producers and consumers | from $3,500 | 3 to 5 weeks |
What it sits next to
Built as part of custom development. It underpins message queue and background job infrastructure and often sits behind an API gateway. See it running underneath digital goods marketplace automation and the Telegram and web marketplace with instant delivery.
Get in touch and tell us which systems need to react to the same events.
FAQ
How much does webhook and event bus infrastructure cost?
A single webhook receiver with signature verification, retries and a dead-letter queue starts at $1,500. A fuller event bus that routes events to several internal services runs $3,000 to $7,000, depending on how many event types and consumers you have.
How long does it take?
2 to 4 weeks for most setups. That covers building the receivers, the queue or broker, and dead-letter handling. We also run real traffic through it in parallel with your existing process before cutting over.
What is the stack?
Redis Streams for lighter setups. RabbitMQ or a managed broker for higher volume or stricter delivery guarantees. FastAPI or Node.js services on both ends, as producers and consumers. The choice depends on your existing stack and expected event volume, not a default we push on everyone.
Who owns the code and the queue?
It is yours on payment, as set in the contract, with read access from day one. It runs on your infrastructure or a VPS in your name. Every event type and consumer is documented, so a future developer can extend it without reverse-engineering the code.
What happens to an event that keeps failing?
It moves to a dead-letter queue after a set number of retries, instead of retrying forever or dropping silently. A person reviews it, fixes the underlying issue, and replays the event instead of losing it.