A webhook and event bus layer
that does not lose a message when a service restarts

What it is

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: instead of the webhook handler calling three other services directly and failing in a confusing way if one of them is slow, it publishes an event once, and each consumer picks it up independently, at its own pace, with its own retry logic.

When you need it (and when you do not)

You need this once a single webhook handler has grown branches, “if this is a payment event, update the CRM, send a Telegram alert, and update the warehouse,” because that pattern fails in exactly the way you would expect: one slow or down dependency blocks or breaks the whole chain, and 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, which is normal, not a bug on their end, and your current handler was not built to expect it.

You do not need a full event bus for a single webhook feeding a single downstream action, that is a receiver with retry logic, which is a smaller, cheaper build. An event bus earns its cost when at least two or three consumers need the same events independently.

How we build it

For most clients we start with Redis Streams, which handles the common case, several consumers, replay, consumer groups, without the operational 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, prevents a retried delivery from double-processing. Events that fail after a defined retry count move to a dead-letter queue rather than disappearing, with enough context logged to debug without replaying the whole stream. We added exactly this kind of event layer underneath a digital goods marketplace’s order and fulfillment flow, where a single purchase event has to trigger delivery, notification and accounting updates independently.

What to watch

The main cost of an event bus is operational, not financial: it is another piece of infrastructure to monitor, and a queue that silently backs up is worse than a webhook that fails loudly, because nothing looks broken until a consumer is hours behind. We build monitoring on queue depth and consumer lag into the initial setup for exactly this reason, not as a later add-on. Vendor lock-in is low for Redis Streams or RabbitMQ, both are open source and self-hostable, but a managed broker service does tie you to that provider’s pricing and API, which we flag before choosing it. The other real risk is event schema drift: a provider changes a payload’s shape without warning, which is the same schema-change problem our API integration work handles, and we apply the same alerting here.

We also recommend separating event types that are safe to replay from ones that are not: replaying a payment-confirmed event twice is harmless if consumers are idempotent, but replaying a stock-decrement event carelessly can double-count inventory, so replay tooling needs the same care as the original delivery path.

Price and timeline

Related

Built as part of custom development. 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. Tell us which systems need to react to the same events: get in touch.