The basics of event-driven architecture

Photo by Clint Adair on Unsplash

The basics of event-driven architecture

Event-driven architecture is a software design pattern that is used to build scalable and loosely-coupled applications. At the heart of this architecture is the concept of an "event", which is any change in state that is important to the system. Examples of events include a new customer order, a change in inventory levels, or a user logging into a system.

In an event-driven architecture, a system is broken down into smaller, more manageable services that are connected by events. Each service is designed to perform a specific function or task, and it communicates with other services by sending and receiving events. When an event occurs in one service, it can trigger one or more other services to perform their own tasks in response.

The benefits of using an event-driven architecture include increased scalability, flexibility, and fault tolerance. By breaking down a system into smaller services that communicate through events, the system can handle large volumes of data and adapt to changing business requirements more easily. Additionally, because each service can be developed and deployed independently, the overall system is more resilient to failures and downtime.

What is an event?

An event in event-driven architecture is a specific occurrence or change in the state of a system, such as a user interacting with an application, a device sensor detecting a change, or a database update.

Different events occurring across a timeline

Think of an event as a notification that something has happened or needs attention. For example, when you receive a notification on your phone for a new message or email, that's an event. Similarly, when a company's inventory levels drop below a certain threshold, that could trigger an event to reorder supplies.

Events are the building blocks of event-driven architecture, which is a software architecture that emphasizes communication between loosely coupled components. In this architecture, components can be designed to react to specific events, allowing for a more flexible and scalable system.

In essence, events are the signals that trigger actions in an event-driven system, allowing it to respond quickly and efficiently to changes in the environment or user interactions.

What is a microservice?

In an event-driven architecture, a microservice is a small and independent piece of software that performs a specific function within a larger application.

Think of microservices as individual components in a system, each responsible for a specific task, such as processing payments, managing customer profiles, or sending notifications. These microservices are designed to be lightweight, flexible, and easy to deploy and scale independently, which makes them a popular choice for building modern applications.

To understand microservices, imagine a restaurant kitchen where each chef is responsible for preparing a specific dish or ingredient. Each chef works independently but collaborates with others to create a complete meal. Similarly, microservices work together to provide the functionality of a larger application, with each service focused on a specific task and communicating with others as needed.

Microservices allow for faster development and deployment of software, as changes can be made to a specific service without affecting the entire system. They also offer greater flexibility and scalability, as individual services can be scaled up or down as needed, depending on demand.

Overall, microservices are a key component of event-driven architecture, enabling developers to build complex applications that are flexible, scalable, and resilient to change.

What are the parts of an event-driven system?

Event sources

These are the entities that generate events within the system. Examples of event sources include user interactions with an application, sensors that detect changes in the environment, or other software systems that generate notifications.

Event Sources

Event consumers

These are the entities that receive and process events within the system. In a microservices architecture, each microservice might act as an event consumer, processing events related to its specific function.

Event consumers

Event bus

The event bus is a central communication channel that enables events to be exchanged between event sources and consumers. The event bus ensures that events are delivered to the appropriate consumers, and can be used to implement various event-driven patterns such as publish/subscribe or point-to-point messaging.

Event bus

Event processors

These are the components that process events once they are received by an event consumer. Event processors might include functions that perform data validation, filtering, transformation, or other operations on the incoming event data.

Event processors

Event storage

Event storage is the database or storage system used to persist event data. In some cases, event storage might be used to store event data for a limited time, while in other cases, it might be used to build a historical record of all events in the system.

Event storage

Consumers and Processors?

In an event-driven system, there are typically two types of components that consume events: event consumers and event processors. While these two components have some similarities, they serve different purposes in the system.

Event consumers are components that subscribe to one or more event streams and receive events as they occur. Event consumers are typically responsible for processing events in real time and taking some action based on the event data. For example, an event consumer might receive an event indicating that a new order has been placed, and then update a customer's account with the details of the order.

Event processors, on the other hand, are components that perform more complex processing on the event data, such as aggregation, filtering, or transformation. Event processors typically receive events from one or more event streams, process them in some way, and then produce new events or data as output. For example, an event processor might receive a stream of sensor data from a set of IoT devices, aggregate the data over a specific time window, and then produce a new event indicating the average value of the sensor data over that period.

Event Storage and event sourcing

Event storage is a type of database or storage system that is used to store events in an event-driven architecture. In this type of storage, events are stored as individual records in a database, with each record representing a specific event that has occurred in the system.

Event sourcing, on the other hand, is a pattern for building event-driven systems that use event storage as a primary mechanism for data storage. In this pattern, the state of the system is derived from the sequence of events that have occurred, rather than from a traditional database or data model.

To understand how event sourcing works, let's use the example of a banking application. In a traditional system, the account balance for a customer would be stored as a single value in a database. In an event sourcing system, the account balance would be calculated by aggregating all of the transactions that have occurred on the account. Each transaction is stored as a separate event, which includes information such as the transaction amount, the date and time of the transaction, and the account numbers involved.

When a request is made to view the account balance, the system reads all of the transactions for the account from the event storage and calculates the current balance based on the sequence of events. This approach provides a more detailed and auditable history of the account and allows for easy reconciliation of account balances.

Event sourcing has several benefits, including:

Auditable history

The use of event storage provides a detailed and auditable history of all events in the system, which can be used for auditing and compliance purposes.

Flexible querying

Because event-sourcing systems store data as individual events, it is easy to query and analyze data in different ways, without being constrained by a fixed data model.

Resilience and fault-tolerance

Because events are stored in a durable and fault-tolerant storage system, event sourcing systems are more resilient to failures and can recover more easily in the event of a failure.

Scalability

Event sourcing systems can be scaled horizontally by adding more event processors, which can process events in parallel and increase the overall throughput of the system.

Hydrating Data

In event sourcing, the state of a system is derived from a sequence of events that have occurred, rather than being stored in a traditional database or data model. This approach provides a more detailed and auditable history of system events, which can be used for auditing and compliance purposes.

However, at some point, it may be necessary to "hydrate" a database with the current state of the system, to support traditional querying and reporting operations. Hydration refers to the process of rebuilding the current state of the system from the event stream and storing it in a traditional database or data model.

This gives us a new super-power. Since we can build data sets at any time from our event store, this means the up front design of a data store is less important. We can re-design it later and pump the data back into the new structure with little to no effort.

Here are the steps involved in hydrating a database from an event stream:

1) Read events from the event stream

The first step in hydrating a database is to read all of the events from the event stream that are relevant to the system state being hydrated. This might include events related to user accounts, product catalogues, or other system entities.

2) Rebuild the state of the system

Once the relevant events have been read from the event stream, the next step is to rebuild the current state of the system based on those events. This involves processing the events in the correct order and applying any business rules or calculations required to derive the current state.

3) Store the state in a traditional database

Once the current state of the system has been derived, it can be stored in a traditional database or data model. This allows the system to be queried and analyzed using standard SQL or other database querying tools.

Hydrating a database from an event stream provides several benefits:

Detailed and accurate history

Because the event stream provides a detailed and accurate history of all events in the system, it is possible to rebuild the state of the system at any point in time and to perform an accurate historical analysis.

Auditable and compliant

By using event sourcing and hydration, organizations can ensure that their systems are auditable and compliant and that they have a detailed record of all system events.

Scalability

Event sourcing and hydration provide a scalable mechanism for building systems that can handle large volumes of data and high levels of concurrency, while also providing a more flexible and adaptable data model.

Which Businesses Can Benefit Most from All This?

Event-driven microservices can benefit a wide range of businesses, particularly those that require high levels of scalability, reliability, and real-time processing. Here are some examples of businesses that might benefit the most from event-driven microservices:

E-commerce

E-commerce businesses can benefit from event-driven microservices to process high volumes of transactions, such as purchases, returns, and refunds. By breaking down the application into smaller, independent services that communicate via events, these businesses can scale more easily and handle large volumes of traffic.

Financial services

Financial services businesses, such as banks or trading platforms, can benefit from event-driven microservices to process real-time market data, transactions, and risk management. By using event-driven architectures, these businesses can respond quickly to changes in the market and provide more reliable and accurate services to their clients.

Logistics and transportation

Businesses in the logistics and transportation industries can benefit from event-driven microservices to track shipments, optimize routes, and manage inventory. By using real-time event data, these businesses can respond quickly to changes in demand or delivery schedules, and provide more efficient and reliable services to their customers.

Healthcare

Healthcare businesses can benefit from event-driven microservices to process real-time data from medical devices, patient records, and clinical trials. By using event-driven architectures, these businesses can respond quickly to changes in patient conditions and provide more personalized and effective care.

Competency

Businesses that require competency assessments, such as training providers, can benefit from event-driven microservices to process assessments and feedback data in real time. By using event-driven architectures, these businesses can respond quickly to the changing needs of learners and improve the quality of their training programs.

Compliance

Businesses that must comply with regulations, such as those in the healthcare, financial, or legal industries, can benefit from event-driven microservices to monitor compliance and audit trails. By using event-driven architectures, these businesses can ensure that they are meeting regulatory requirements and can quickly respond to any compliance issues that arise.

IoT (Internet of Things)

Businesses that use IoT devices, such as sensors, smart devices, or wearables, can benefit from event-driven microservices to process real-time data from these devices. By using event-driven architectures, these businesses can respond quickly to changes in the environment or user interactions, and provide more personalized and efficient services to their customers.

Conclusion

Event-driven architecture and microservices provide numerous benefits to businesses of all sizes and industries, particularly those that require high levels of scalability, reliability, and real-time processing. By breaking down applications into smaller, independent services that communicate through events, businesses can scale more easily and handle large volumes of data, adapt to changing business requirements, and improve overall system resilience. Additionally, event sourcing and hydration provide a detailed and auditable history of all events in the system, making it possible to rebuild the state of the system at any point in time and perform accurate historical analysis. Overall, event-driven microservices are a powerful tool for building complex, flexible, and adaptable systems that can respond quickly and efficiently to changes in the environment or user interactions, providing businesses with a competitive advantage in today's fast-paced digital landscape.