What is a event-driven?
Event-driven means systems communicate by emitting and reacting to events instead of synchronous request-response calls. The source announces "thing X happened" as an event, and any number of subscribers react independently — including ones the source has never heard of. This buys three properties: decoupling (adding a subscriber doesn't require source-side changes), asynchrony (the source emits and moves on), and resilience (a down subscriber gets a queue backlog instead of breaking the source). The trade-off is eventual consistency — you don't immediately know whether a downstream handler succeeded — which idempotent handlers and event logs help manage.
Event-driven architecture is the broader pattern that webhooks belong to. The basic idea: instead of service A calling service B to "make B do thing X," service A announces "thing X happened" as an event, and any number of subscribers — including service B, but also potentially service C, D, and E — react to it independently.
Compared to synchronous RPC, event-driven systems have three properties. Decoupling: the source doesn't know who's listening, so adding new subscribers doesn't require source-side changes. Asynchrony: the source emits and moves on; subscribers process at their own pace. Resilience: if a subscriber is down, events accumulate in its queue and process when it recovers — the source is unaffected.
Webhooks are the cross-organization version of event-driven: when Stripe announces charge.succeeded, your system reacts. Internally, the same pattern uses different transports — Kafka, NATS, RabbitMQ, Postgres LISTEN/NOTIFY, AWS SQS — but the architectural shape is identical: producers, events, subscribers, queues.
What event-driven systems trade for those properties is complexity in reasoning about state. In an RPC system, after charge(amount) returns, you know the charge succeeded. In an event-driven system, the source's "charge succeeded" event arrives at some unknown later time, and your system must operate in the interim with the charge in a "pending" state. Eventual consistency is the technical name for this; "I don't know yet whether the payment worked" is the human description.
Three patterns make event-driven tractable. Idempotent handlers, so a duplicate event doesn't break anything. Event sourcing or event logs, so you can replay events after a bug fix. Consumer-side filtering, so each subscriber processes only the event types it cares about — not every event the source emits.
For webhook integrations specifically, "event-driven" is less of a choice and more of a constraint: the provider has chosen to expose its events as webhooks, and your job is to be a competent subscriber. The competence checklist is in the rest of this glossary — verify, deduplicate, queue, retry-tolerate, observe.
See Event-Driven in real traffic
WebhookWhisper captures every webhook with full headers, body, signature, and timing — so concepts like event-driven stop being abstract and become something you can inspect.
Start Free