Choose an event-processing architecture for an application

Types of event-driven applications

Event-driven applications fall into two primary categories. In both, an Event is a simple signal of conditions or a change in conditions.

The first is a true event application, where external conditions signal for application attention by a set of sensors or other means. Many industrial event-driven systems and IoT applications fit into this category.

The second type of event-driven application is one designed with the decomposed transaction model, where an online activity -- usually a multistep process transaction -- is broken down into steps that are then processed as events. Many online social networks act this way.

Even in IoT applications, events usually need context, based on the state of the system. For example, an application raises and lowers a traffic gate. A signal that the gate is coming down either indicates successful event processing in response to a request to lower it, or a major fault if the request was to raise it. An event requires the application's overall current state information to be correctly processed. Event processing is often called state/event processing for this reason.

State control models

To define an event-processing architecture, first decide how to control state. State control can occur in the form of an imposed or interpreted state model.

In an imposed state model, the application derives the state of the system based on the progression of presented events. This model suits an architecture with stored state.

For an interpreted state model, the system infers state by correlating a series of events, often from different sources and occurring over a period of time. This model works with complex event-processing application architectures.

Stored-state control approaches

Stored-state event-processing architectures have three possible approaches: source-defined state, back-end state control with a database and state orchestration.

A source-defined state technique ensures the current state of the system is communicated with the event. This approach is often the easiest, because the source is closest to the physical system generating the events and the place where state is easiest to determine. The application architect should decompose a transaction into separate events.

The browser and web server -- or the app in use -- maintain an indicator for where it is in the multistep dialog, and this indicator is passed to subsequent processes. Source-defined state is risky if the state changes later in the transaction process, because a mechanism must communicate that change back to the source to synchronize the state.

For back-end state control, the application's current state is stored in a database for reference by any process, avoiding the risks of state change. Any process can read and write information in a back-end database, so a state change can be made anywhere and reflected everywhere. The risk lies in collision when reading and writing the back-end database.

With back-end state control, architects must allow only one process to write state changes, which means next-state determination should link with the event table processing and not with the individual processes. This is actually a best practice for all state control implementations.

A traditional event table process could be expressed as, "If Event occurs in State, run Process Set X and set Next State to Y." The state-event combination always sets the successor's state, and only one process -- that which looks up the event in the event table -- sets the state. The alternative to this single-process approach is to apply write collision protection to the back-end database updates, so two processes cannot write the state at the same time.

For state orchestration, the application relies on an external system to maintain state and select processes to run in response to the state-event combination. The single process, as seen in the back-end state control model, is outside the application. Orchestrated applications, using products such as AWS Step Functions or the Knative open source platform originating from Google, let the package decode the state-event combination and run the appropriate functions.

How complex event processing differs

While, in many cases, complex event-processing applications use state control approaches that overlap with those of stored-state systems, this architecture has distinct differences, too.

Generally, complex event processing presumes so many different possible external states exist for a system that it is not practical to track state explicitly through a progression of events. The system is often made up of a large number of somewhat autonomous subsystems, each of which might have its own state-event progression. When architects cannot model the system, they instead must interpret it by directly analyzing the sequence and timing of events.

The most complicated issue in event processing is perhaps that everything is event-linked, yet many activities are easily framed as sequences of events, as well. Development planners should look at their applications carefully to make the best choice.