Event-Driven Architecture

An event describes an occurrence such as an order being placed, whereas a command asks a component to perform an action. Consumers decide how to respond to events, often through brokers or retained logs. This separation enables multiple reactions without the producer calling every consumer directly, but it introduces asynchronous timing and failure behavior. Delivery may be repeated, ordering may be scoped and consumers may observe state at different moments. Architecture therefore includes contracts and reconciliation, not just a messaging technology. It differs from stream processing, which computes over event flows, and can support either real-time processing or slower asynchronous workflows.

The practitioner defines event ownership, schemas and identifiers, then designs consumers that can retry safely. They record ordering requirements and choose mechanisms for publishing events consistently with state changes. Useful artifacts include event contracts and sequence diagrams for failure and recovery. Observability should connect a business operation across asynchronous steps without assuming one synchronous trace captures everything. The team also plans version evolution, dead-letter handling and reconciliation, ensuring that an event is not considered successfully handled merely because a consumer acknowledged receiving it.

Decoupling can obscure the real business process and make end-to-end failures harder to diagnose. Events are not automatically durable, ordered or exactly once, and poorly defined schemas can bind consumers tightly to producer internals. Eventual consistency must be acceptable for the task. A strong design demonstrates retry safety and recovery across components; adding a broker alone does not establish a reliable asynchronous system.