What is event-driven architecture?

Producers, routers, and consumers

A producer recognizes that something happened and publishes an event. A router, bus, stream, or broker evaluates where that event should go. One or more consumers receive it and perform their own work without the producer calling each consumer directly.

This separation can reduce temporal and deployment coupling. It also creates new contracts around event shape, routing, delivery, ordering, retention, replay, and the point at which an operation is considered complete.

Design events as durable contracts

An event should describe a fact in the language of the domain, identify when it happened, and carry enough context for authorized consumers to act. Avoid exposing internal database rows as the public contract by accident.

Plan for schema evolution before the second consumer exists. Define required and optional fields, compatibility rules, ownership, sensitive-data handling, versioning, and how consumers behave when they receive an event they do not understand.

Delivery, duplicates, and failure

Many event integrations can deliver more than once, delay delivery, or process different partitions concurrently. Consumers should be idempotent where duplicates are possible and should not assume ordering unless the selected service and partitioning model provide it.

Use retries for transient failures, dead-letter or failure destinations for work that cannot proceed, and alarms on age and backlog rather than errors alone. A recovery path must explain how an operator inspects, fixes, and safely replays failed events.

When event-driven architecture is useful

Events are useful when multiple reactions follow one business fact, when work can happen asynchronously, when traffic needs buffering, or when producers and consumers must scale and deploy independently.

A synchronous request can be clearer when the caller needs an immediate result or the operation has one tightly owned path. Most systems combine synchronous commands with asynchronous events instead of forcing every interaction into one style.