Event-Driven Architecture - strategic questions

Event-driven architecture is a software paradigm in which services and applications communicate asynchronously through publishing and consuming events. An event is anything that happens in a business environment or their customers’ ecosystem.

An obvious advantage is that services can be decoupled because of the asynchronous communication. This means they no longer need to rely on each other for scaling and don’t impact other services in case of failure.

Working with events also makes real-time data processing possible from several sources: not just software applications and services, but all kinds of IoT devices as well.

It is not. Though an event hub such as Kafka is an essential component in an Event-Driven architecture.

A distributed event-handling architecture can scale as the number of entities generating events increases. Processing of the events in a topic is handled by consumers that can individually scale horizontally up to the number of partitions of that topic. The number of partitions is important to guarantee ordering. In other words, consumers have the flexibility to process the data at their own pace

Using Event-Driven Architecture has proven to have numerous benefits for both business and IT environments. An obvious advantage is that services can be decoupled because of the asynchronous communication. This means they no longer need to rely on each other for scaling and don’t impact other services in case of failure. During development teams can independently deploy new features or improve their service.

Working with events also makes real-time data processing possible, originating from different sources: not just software applications and services, but all kinds of IoT devices as well. Organisations will be able to make more and quicker decisions, based on data they can trust. By increasing responsiveness, companies can innovate faster and set themselves apart from the competition.

• Business events: Events that have business value and that express something that happened in a business process, e.g. ContractSigned. These events contain data that is known by business.

• State transfer events: Events that hold the latest state for a data entity. These events don’t tell you what has happened or changed, they hold the latest state which is useful for aggregation of data or creating views / data caching.
  
• Raw machine events: Often IOT events. Raw events, hard to read.
• Internal events: Events that are only used in 1 microservice. They don’t hold important business data that should be produced as a business event.

Events are designed in a similar fashion as other data models. They always express something that happened in the past so they need to be named in the past sense, e.g. ContractSigned, not SignContract.

The payload should hold all relevant information for that event, better too much information than too little.

It’s useful to agree on a common set of headers for all events in an organisation such as timestamps, event name.

Event sourcing is an alternative way to persist data. In contrast with state-oriented persistence that only keeps the latest version of the entity state, event Sourcing stores each state mutation as a separate record called an event.
By reading all events for an entity the latest state can be derived.

An Event-Driven Architecture introduces new patterns and concepts such as asynchronous processing, eventual consistency, read models. This might introduce some technical challenges if you don’t have experience with those.

The handling of errors is more intricate, it’s important to make sure events are always produced, not in a separate transaction. Eventual consistency means less predictability for timing, but also better scalability and faster systems in general.

Storing event logs for a longer time is supported by most event hubs, which means a backup solution or an active-passive cluster setup needs to be set up.