Event streaming revolves around the unbounded, sequential and real-time flow of data records called "events,” foundational data structures that record any occurrence or change in the system or environment. Examples of such changes include a user adding an item to their shopping cart on an e-commerce site or requesting to reset a password or an application state change. It’s a term that essentially refers to every data point in the system. And a “stream” (also called a data stream or streaming data) is the continuous delivery of those events.

Each event typically comprises a key that identifies the event or the entity it pertains to, a value that holds the actual data of the event, a timestamp that indicates when the event occurred or was recorded, and sometimes metadata about the event source, schema version or another attribute. They can either carry state data (the item purchased, its price and a delivery address, for instance) or serve as identifiers (a shipping notification).

With the help of specialized stream processing engines, events can undergo a few different processes within a stream. “Aggregations” perform data calculations, like means, sums and standard deviation. “Ingestion” adds streaming data to databases. Analytics processing uses patterns in streaming data to predict future events, and enrichment processing combines data points with other data sources to provide context and create meaning.

Events are often tied to business operations or user navigation processes and typically trigger another action, process or series of events. Take online banking, as one example. When a user clicks “transfer” to send money from one bank account to another, the funds are withdrawn from the sender’s account and added to the recipient’s bank account, email or SMS notifications are sent to either (or both) parties, and if necessary, security and fraud prevention protocols are deployed.

In addition to events, EDAs rely on three primary components to move event data through the architecture.

• Event producers (or publishers): Producers are the sources of events; they generate events and send them to the rest of the system. A producer could be a user interface, a sensor, a service or any other system capable of detecting or producing a state change of interest to other parts of the system. Though producers are responsible for creating events, they have no event processing functionality.

• Event consumers (or subscribers): Consumers handle the event processing tasks in an EDA. They listen on event channels and react when an event of interest is published. The reaction can take many forms, including updating a database, triggering a downstream process or simply logging information.

• Event routers (or event orchestrators): Routers, or orchestrators, are the brokers that decouple front-end event producers from backend event consumers; they serve as the conduits through which events are delivered, ensuring transmission without requiring a direct connection between the entities. Routers can be based on conventional components (message-oriented middleware, like a SaaS, for example) and be useful in a range of messaging systems (message queues, publish/subscribe models, event streams, and more.).

In an EDA, event-driven applications act as producers or consumers (and sometimes both).

When an app or service performs an action that another app or service might want to know about, it publishes a new event—a record of that action or change—that another service can consume and process to perform other actions. 

The event producer then transmits the event—in the form of a message—to a broker or another type of event router, which maintains the event’s chronological order relative to other events. An event consumer ingests the message—in real time (as it occurs) or in a later relevant instance—and processes the message to trigger another action, workflow or event of its own.

In a simple example, a banking service might transmit a “deposit” event, which another bank service would consume and respond to by writing a deposit to the customer’s statement.

But event-driven integrations can also trigger real-time responses based on complex analyses of huge volumes of data, like when a customer clicks on a product on an e-commerce site and the system generates instant product recommendations based on other customers’ purchases.

In addition to the two primary EDA architectural patterns, three design patterns govern how events are processed once they reach the subscriber.

• Simple event processing: where consumers process events exactly as they’re received from publishers, triggering immediate action.

• Event stream processing (ESP): where data streaming platforms ingest events and build a pipeline to stream processors, which then process and transform the stream.
  
  
• Complex event processing (CEP): where consumers process a series of events to identify trends and patterns in the data. 

All three processing patterns (among others) can be used within both publish/subscribe and event streaming architectural patterns, but ESP is (naturally) most common in the event streaming architectural pattern.

EDAs can be useful for businesses operating in myriad sectors, but they’re especially valuable for businesses with large, complex IT environments.

Enterprises attempting to integrate systems running in different tech stacks, for example, can use the decoupling features of event-driven architectures to keep event data system-agnostic and improve interoperability. Multinational corporations can use an EDA to coordinate systems across accounts and regions, facilitating independent scaling of different parts of the architecture. And for businesses running systems that each process different parts of an event, the fan-out features of EDAs can push events to each consumer—without needing new code—for parallel processing across the system.

In e-commerce, an event-driven architecture can filter and route events in real time to make sure they go only to subscribers interested in their data. New purchases go directly to order processing consumers, order issues are routed directly to customer service channels, and so forth.