An event's lifetime lasts until the next event.
By
Mathias Verraes
Published on 23 May 2019
An event’s lifetime lasts until the next event.
Some producers, such as sensors, emit realtime or near-realtime measurements, expressed as events. A new measurement makes the previous measurement obsolete. These events can be sent at regular or unpredictable intervals, but they are often high frequency. Consumers aren’t capable of keeping up with all events, or aren’t interested in processing all of them.
Mark the events as being Ephemeral Events. The infrastructure knows that only the latest event matters. When a consumer can’t keep up with the event stream coming in, the infrastructure prefers to drop older events and skip to the most recent one. The consumer can still produce valuable outcomes with a subset of all events.
In an eventsourced system, the Ephemeral Events are not persisted. Partly this is because there are too many of them. More importantly, they have no lasting business value, or at least not at their original level of granularity. An @ephemeral annotation in the code can indicate to the eventsourcing infrastructure that this event must not be persisted.
A thermometer emits TemperatureWasMeasured { temperature, timestamp } events multiple times per second. A consumer updates a graph on a TV monitor once a minute, and ignores the other events. The consumer is turned off during the night. In the morning, it doesn’t catch up with the nighttime events, but picks up from the latest one.
Ephemeral Events are often combined with other patterns:
Ephemeral Events should not be confused with Message Expiration, as described in Enterprise Integration Patterns, where the message itself contains an expiration date by which it is no longer relevant.