Event Stream
Event streams combine durable history with independent reader positions.
- PartitionDefines ordering and the unit of parallel processing.
- OffsetMarks the read progress of a consumer group.
- RetentionLimits the time and extent of possible replay.
Context
Why this is important
Replayability is only as strong as retention, schema evolution, and replay safety.
The analytics platform is hypothetical; currently the shop uses seven modules and shared infrastructure.
Stream decisions
The current shop remains a modular monolith with seven modules. For a hypothetical analytics platform, order events are partitioned by order ID and retained for 90 days. Shipping reads live with its own group; Analytics builds a projection from its offset. The team deletes the analytics projection, replays available history, and checks per-order ordering, schema capability, and idempotent processing. It explicitly documents which view could only recover from a snapshot after retention expires.
This is how you read the picture
- Partition Order ID as key
- Offset Store after effect
- Retention Snapshot for older states
| Comparison | Decision | Gain | Consequence |
|---|---|---|---|
| One partition | Global ordering | Simple offset | Limited throughput |
| Keyed partitions | Parallelism | Ordering per key | No global ordering |
| Time retention | Bounded storage | Replay within window | Older baseline needs snapshot |
Benefits & limitations
Helps if:
- Several readers need the same event history.
- Projections should rebuild after failures or code changes.
- Ordering per business key is sufficient.
Boundaries
- Retention can remove older events before a full replay.
- More partitions increase parallelism but remove global ordering.
- Replay can retrigger external effects and needs separate safeguards.
In practice
- Read OrderConfirmed with separate offsets for shipping and analytics. Record how long a late-starting reader can still query the event history.
- Reset a reader to an earlier offset and compare the rebuilt projection with its control value. Plan for duplicate handling.
- Assess partition key, ordering, and retention for shop events. State which query becomes impossible if the retention window is too short.
Read the detailed explanation
Publishers append immutable events to a partition. An offset identifies their location; consumer groups independently store how far they have processed.
Partitioning determines parallelism and ordering boundaries. Replay enables new projections and repairs but requires available history, compatible schemas, and idempotent effects.
Publish-Subscribe explains fan-out to subscribers. Event Sourcing uses events as authoritative business state; a stream alone does not make that modeling decision.
Check your understanding
Test yourself in three stages
ReadingCheck in the picture
Where does ordering typically apply?
View the solution with justification
Within a partition.
ApplyingTransferred to a new situation
How does Analytics rebuild its view?
View the solution with justification
From a snapshot or starting offset plus all events available within retention.
EvaluateWeighing an alternative
Why is a stream not automatically event sourcing?
View the solution with justification
Because the events are not necessarily the authoritative business state.
Explore further
These building blocks continue the thoughts of this page.