When building event-driven architectures your architecture may consist of streams (series) of unbounded events (events that never end), or discrete events (events that are facts, they happened). Depending on your use-case will depend on which you may have, and many folks will have and need both. Often starting with discrete event use cases though (where consistent and easy event subscription, routing, and filtering are common requirements).

When trying to understand the difference, you need to understand what you want to act on and process. For example if have an IOT temperature sensor that raises events, you may want to consume these events and process them in “micro” batches, let’s say every 5 minutes (processing a stream of events). Once we process these events, we can add business logic to determine if something of interest has happened, an example could be that the temperature fell below our threshold we set, then we can raise an event (discrete event) to notify downstream consumers of something significant that happened.

Streaming events

• Think of a stream of events as unbounded data, they are continous and may never end.

• Processing these events can differ from processing discrete events. For example you may be interested in batching these events (e.g by time, collection, user), perform stateless (counting) or stateful (joins) operations, and then raising events from what was processed.

• Common examples of streaming events would be IOT (telemetry) sensors, Click streams on a website, credit card transactions.

Discrete events

• Think of discrete events as significant (important) facts that have happened, and you have downstream consumers that want to act on this information.

• Example would be an OrderPlaced, CustomerMoved, PaymentRejected events.

• Discrete events can be raised from business applications, such as an order service in a restaurant, or from processing a stream of events for analytical purposes. If you process a batch of events from a stream, you may want to analyze this information and rise an event to let the system know something has happened.

When to use streaming or discrete

• Many event-driven architectures may use both streaming and discrete events, it really depends on your consumer semantics. What are you trying to act on? What information do you have? What is your business use case? What do your consumers need e.g., event filtering/routing, error handling, programming language support, knowledge around a particular solution or make the system opaque to decrease coupling

• Streaming events allows you to capture an open ended amount of events/information you may want to act upon - often the value is not within a particular event, but in the series/group of related events (“high volume, low value“)

• Discrete events allows you to rise facts in the system of things that have happened, these facts can from various sources, and one of them might be processing a stream of events hitting certain business criteria. Discrete events itself have value to the consumer, i.e., they represent a significant fact/change consumers (subscribers) will act upon

Extra Resources

• Dive deeper into event-driven architecture - Want to learn more about event-driven architecture? There are over 40 visuals for you to dive deep and learn.
• Batch processing vs event streaming - A further dive into what are event streams and what is batch processing.
• Understanding event streaming - Want to continue to learn about event-streaming? Understand real-time data, flow of events and log based brokers.
• Use EventBridge Pipes and Event Buses to process discrete events from many event sources, such as AWS events, Amazon Kinesis, and Apache Kafka
• Serverless Office Hours: Integrating EventBridge with Apache Kafka