Event-Driven Architecture: Services That React to Events

In an event-driven architecture, services do not call each other to get things done. Each service announces what has happened, an event such as "order placed", on a broker, and any service that cares subscribes and reacts. The service that announced it does not know who reacted, or when.

How it differs from microservices. Microservices describes how the application is divided: separate services with their own data. Event-driven describes how they talk: through events rather than calls. The two are often combined, and an event-driven system is usually built from microservices.

What it makes easy. A new reaction is a new subscriber, with no change to the service that announces. A slow or failed service does not slow the others; its events wait for it. Bursts are absorbed by the broker. And the stream of events is a record of what happened, which other systems can read later.

What it makes hard. No single place shows the whole flow of an order: it is spread across subscribers. Following one order through the system needs tracing by an id carried in every event. Events can arrive twice or out of order, so every subscriber must cope. And the system is eventually consistent: for a moment, the warehouse may know about an order that email does not.

A company known to use it. LinkedIn built Apache Kafka, a durable log of events many services can read, to carry its activity events between systems, and released it as open source in 2011.

So choose events when many services must react to what happens and none should wait on another, and invest in tracing before the flows become hard to follow.