Understanding the fundamentals of events

Event-driven architecture revolves around events. Understanding the fundamentals of events is crucial for designing and implementing robust event-driven architecture systems. This section explores events’ core aspects, characteristics, types, and how they fit into the overall architecture.

What is an event?

An event is a significant change in state or occurrence within a system that interests other system components. It represents an action or condition triggering a response or processing by other system parts. Events are fundamental communication units in event-driven architecture, allowing systems to react to changes in real time.

Characteristics of events

Events have characteristics that define their nature and how they are handled within an event-driven architecture system:

• Immutable: Events must be immutable, meaning they cannot be altered after publication. This ensures consistency across distributed systems. If a correction is needed, a new compensating event should be emitted instead of updating an existing one.
• Temporal: Events occur at a specific point in time. They often include timestamps to indicate when the event took place.
• Descriptive: Events carry information about what happened and may include relevant data or metadata. This data helps consumers understand and process the event.
• Asynchronous: Events are typically processed asynchronously, allowing for decoupled and independent operations between producers and consumers.

Events can be classified into some types; let’s explore them.

Acknowledging the types of events

Events can be categorized based on their nature and purpose:

• Simple events: Basic occurrences that do not involve complex logic or multiple conditions are known as simple events. They usually involve a straightforward action or change in state and typically carry minimal information. These events are often used in systems where real-time processing is crucial. For example, a temperature sensor reading in an IoT system might generate simple events every time a new reading is available.
• Composite events: Composite events are complex events composed of multiple simple events, often representing a higher-level condition or pattern. They involve the correlation of multiple simple events and are used for detecting patterns or aggregating information across events. In a security monitoring system, for example, detecting a security breach might involve combining multiple events, such as failed login attempts and suspicious access patterns.
• Domain events: Domain events are significant occurrences within the business domain that reflect a state change or condition that the domain experts care about. They represent essential milestones within the domain, such as Order Placed or Customer Registered. Domain events often carry business-specific data and notify other parts of the system about changes that might affect their behavior. In an e-commerce system, for example, when a customer places an order, a domain event might be generated to initiate processes such as payment and inventory checks.
• System events: System events are related to the internal workings or infrastructure of the system, such as resource availability, performance metrics, or system failures. They are often generated by the system and used for monitoring, management, or maintenance purposes. For example, an event indicating that a server’s CPU usage has exceeded a certain threshold is a system event that might trigger scaling operations.

Events define a schema and contracts between producers and consumers independent of the event type. Let’s understand what event schemas and contracts are.

Event schemas and contracts

Events are defined using schemas or contracts to ensure consistent communication between producers and consumers. An event schema specifies the structure and format of the event data, including required fields, data types, and any optional metadata. Typical formats for defining event schemas include JSON, Avro, and Protocol Buffers.

Event contracts are agreements between producers and consumers on events’ expected structure and behavior. They provide a shared understanding of how events should be created, transmitted, and processed, reducing the risk of miscommunication and errors.

Fetching data models

In event-driven architecture, the push and pull models are the two fundamental approaches to managing event distribution and processing.

Push model

In the push model, events are actively sent (pushed) to consumers by the event source or an intermediary, such as an event broker. Figure 8.2 illustrates the push model.

Figure 8.2: Push model

When an event occurs, it is immediately dispatched to all subscribed consumers, who then process it in real time. This model is often used in scenarios where low latency is crucial, and events must be processed as soon as they occur. For example, the push model ensures that users receive updates instantly in a real-time notification system.

Message brokers and cloud services implementing the push model include RabbitMQ and AWS Simple Notification Service (SNS).

Pull model

In the pull model, consumers actively request (pull) events from an event source or intermediary at their own pace. Figure 8.3 illustrates the pull model.

Figure 8.3: Pull model

Instead of being pushed to consumers, events are stored in a queue or topic, and consumers poll this storage periodically to retrieve and process events. This model is helpful in scenarios where consumers must control the event or batch processing rate. For instance, a data analytics pipeline might use the pull model to fetch and process data in manageable chunks.

Message brokers that implement the pull model include Apache Kafka and AWS Simple Queue Service (SQS).

The choice between push and pull models depends on the system’s requirements. The push model is ideal for applications requiring immediate event processing and low latency, but it can lead to issues if the consumer cannot keep up with the event rate. On the other hand, the pull model provides greater flexibility and control over event processing rates, but it can introduce latency due to the polling interval.

In an event-driven architecture system, a combination of both models might be employed to balance real-time processing needs with the ability to handle varying workloads effectively. Now, let’s learn about two common architectural styles for managing interactions and controlling the flow between the services.

Managing interactions and workflow

Event-driven architecture usually employs two common architectural styles to manage and control workflow between services: orchestration and choreography. They are two distinct approaches to managing interactions and workflows in distributed systems. Both methods aim to coordinate the activities of multiple services to achieve a specific business goal, but they differ significantly in their control mechanisms and design philosophies.

Orchestration

Orchestration refers to a centralized approach where a central controller, often called an orchestrator, manages and directs the interactions between services. The orchestrator coordinates the sequence of service invocations and ensures that the overall workflow progresses according to a predefined plan. The following are the main characteristics of orchestration:

• Centralized control: A single orchestrator controls the flow of operations, deciding which services to call and in what order
• Explicit workflow definition: The workflow logic is explicitly defined within the orchestrator
• Ease of management: Centralized control makes managing and monitoring the overall workflow easier, as the orchestrator coordinates all interactions
• Error handling: The orchestrator can implement complex error handling and compensation logic, ensuring the workflow can recover from failures

Figure 8.4 presents the flow of e-commerce using an orchestrator architectural style.

Figure 8.4: Orchestration architectural style

In the orchestration architectural style, a central orchestrator service controls the sequence of operations and interactions between services via a message broker. When a customer places an order, the order service processes it and sends an event to the orchestrator through the event broker. The orchestrator then sends an event to the payment service via the event broker. Once the payment service completes the payment, it sends an event back to the orchestrator through the event broker, which then sends an event to the shipping service. The orchestrator manages the communication between services to ensure each step is executed in the correct order.

Now, let’s learn about another architectural style for managing and controlling workflow between services: choreography.

Choreography

Choreography refers to a decentralized approach where each service independently decides when and how to interact with other services based on events. There is no central controller; instead, services communicate directly with each other, reacting to events and making autonomous decisions. The main characteristics of choreography are as follows:

• Decentralized control: Each service has autonomy and makes decisions based on the events it receives, leading to a more loosely coupled system
• Implicit workflow definition: The workflow emerges from the interactions between services rather than being explicitly defined in a central location
• Scalability and flexibility: The decentralized nature of choreography can lead to better scalability and flexibility, as services can be added or modified without changing a central controller
• Complexity in coordination: Managing the overall workflow can become complex, as there is no single point of control to oversee the entire process

Figure 8.5 presents the flow of e-commerce using a choreography architectural style.

Figure 8.5: Choreography architectural style

In choreography architecture, services communicate by reacting to events from other services without a central coordinator. When a customer places an order, the order service processes it and notifies the payment service. The payment service processes the payment and notifies the shipping service. Each service operates independently, enhancing scalability and allowing independent evolution.

Another fundamental difference lies in the type of messages exchanged in each style. In orchestration, messages are typically commands—explicit instructions sent by the orchestrator to tell a service what action to perform next. The orchestrator determines the flow and actively directs the involved services. In contrast, choreography relies on events, representing facts about things that have already happened. Services react to these events and decide independently what action to take in response. This distinction reinforces the centralized nature of orchestration, where control flows through command messages, and the decentralized nature of choreography, where control emerges from the event stream.

Both orchestration and choreography have their advantages and use cases. Orchestration suits scenarios where central control and explicit workflow definition are beneficial, making managing and monitoring complex workflows easier. On the other hand, choreography is ideal for systems requiring high scalability and flexibility, where services must operate autonomously and respond to events dynamically.

Choosing between orchestration and choreography depends on the system’s requirements, including the complexity of workflows, flexibility, and the desired level of control over service interactions. In many cases, a hybrid use of orchestration and choreography can provide the best balance, leveraging the advantages of each technique to accomplish the desired system behavior.

We have now explored and grasped event-driven architecture. Next, let’s explore important and commonly used event-driven patterns in an event-driven architecture.