A five-point primer on event-driven design

What are the benefits of event-driven architecture patterns?

The stage is set for event-driven design to become the norm. To make applications well-suited to this reality, enterprise IT organizations should start transitioning to event-driven architecture patterns today.

Tech analyst Twain Taylor recommends that architects keep these points in mind:

• Event-driven architectures may seem more complex than those based on procedure calls, but the payoff is flexibility.
• Asynchronous event data is immutable and becomes the backbone of real-time operations and analysis efforts.
• Event-driven architecture patterns may manifest as both one-time events in a stateful application, or as a stream of events across stateless services.
• Events will become an especially important part of application management as IoT devices continue to sprawl across software environments.

Implement and manage an event-driven microservices architecture

Event-driven microservices can replace applications with a monolithic architecture. They can create systems that are more flexible, scalable and easier to maintain. Event-driven design for microservices offers several advantages over legacy systems, but application designers and developers must learn how to approach microservices communication, maintainability and scalability within these event-driven methods. Additionally, teams should decide on an architectural pattern that best fits the application's tasks: event sourcing, polyglot persistence or command query responsibility segregation (CQRS).

In an introduction to event-driven design in microservices, architect Joydip Kanjilal identifies these as the major patterns:

• Event sourcing patterns, where a sequence of events determines the state of the application, and events are delivered in the same order they are received. This pattern uses an append-only event stream, such as Apache Kafka or RabbitMQ.
• Polyglot persistence patterns, where data stores are selected depending on the characteristics of the data types.
• CQRS patterns, which isolate the read model from the write model. There is typically a separate service, model and database for the insert or update operations, as well as for data querying.

Choose an event-processing architecture for an application

More organizations and development teams are now expected to understand and design an event-processing architecture. Doing so successfully requires multiple decisions about state control.

In an advice piece on configuring event-processing architectures, software consultant Tom Nolle recommends that today's architects familiarize themselves with some essential event-processing concepts. Some of the most important steps an architect should remember are to:

• Determine whether the application is directly event-driven or if a set of steps that compose an online activity acts as events to trigger processes.
• Learn how to control state, which can occur in the form of an imposed or interpreted state model.
• Understand the three possible approaches to stored-state event-processing architectures: source-defined state, back-end state control with a database and state orchestration.
• Analyze the sequence and timing of events since it is not always possible to track states specifically through a progression of events.

5 ways to get complex event processing right

Complex event processing (CEP) enables organizations to analyze and use data sourced from disparate streams of information such as IoT devices. There are important considerations to bear in mind when it comes to CEP, from the best time to use it to how the CEP engine will fit with the organization's needs from its data in the future.

In a tutorial that explores the fundamental truths of CEP, industry analyst Clive Longbottom recommends that organizations closely follow these five guidelines:

• Focus on real-time analytics rather than pouring over post-mortem data.
• Use edge processing to filter out unneeded data.
• Adhere to established data standards, such as XML.
• Work with CEP vendors that readily adapt to AI data standards.
• Create a comprehensive plan for your CEP engine implementation.

Use event processing to achieve microservices state management

It's possible to limit your use of stateless microservices to cases where state is not relevant. You could also code state control directly into the microservice, but this approach adds the risk that the services become less agile and portable.

Instead, consider microservices state management with events. An event provides state information for those microservices through a comprehensive event-processing model.

In another tip on managing event processing, Nolle cites three main event-processing strategies that can help maintain state for stateless microservices:

• Design microservices-based applications so that any data associated with the event or process flow gets stored and provided to the right service by matching it with the correct event context.
• Create some form of context ID, which can act as a unique transaction identifier or event flow ID you assign when an event launches a contextual process (this can be as simple as a timestamp).
• Adopt event-processing orchestration as part of the overall microservices state management strategy. Creating a stateful service defines the service workflow model and takes authority over when each service is invoked.