As events are generated in one of the event-driven architecture components and the notifications placed in the channel, the communication pattern used to share them defines also the nature of the messages. By this mean, not all events are equal and not all events carry the same priority or business value in an event-driven architecture.
The system processes events differently depending on the nature and what each event represents for the overall business. For the purpose of better understanding, we have classified events in 3 major types. This event types allow software architects to choose adequate event-driven architecture component implementations that best suit each event type nature.
Volatile
In this type of event the message needs to be disseminated to all consumers available online at the time of publication. Usually this type of event is not persisted in a durable storage and rather is kept in memory or not even accepted by the event management bus. The EDA components handling volatile events must be aware about the connected consumers to the bus.
One example for disposable volatile events could be the information gathered by a temperature IoT sensor. It became volatile when we care only about the average temperature in a long period of time, say a day, month or year. If one of the measurements is not present, and we have a frequent collection, then missing one of those events shall not affect at all the average calculation.
On the other hand, we can have events that are useless if we can’t find a suitable consumer which processes the incoming messages. This is a typical use case for command type events where storing events that might not be consumed by anyone in the near future to take actions makes no sense.
Durable
Events stored durably until read by all registered consumers. The EDA components handling durable events must be aware of the connected consumers and be able to selectively manage the delivery of the messages to those consumers.
This is the event type that most people are familiar with as it is the basic implementation of traditional store-and-forward brokers.
Replayable
Replayable events are stored durably for specific period of time or configured storage capacity. The EDA components handling replayable events store the messages into the persistent storage in a log appender structure. To increase throughput and performance, EDA components for replayable events are not aware of the consumers registered in the system. In consequence, as consumers take ownership of the current pointer position, they can move back and forth of the log reading from the stream of events.
Event-driven Architecture
The type of events produced and consumed by your applications will be key to craft a successful Event-driven Architecture. Check more on the basics of EDA.
Last updated: February 13, 2024