An immutable collection preserves its existing contents after creation: entries are not changed or removed. New information is added separately, so readers can reconstruct how the represented state evolved over time. section 4.1.2
This property is especially useful for data exchanged between services. Once another service may have consumed a record, altering or deleting it can create disagreement; preserving the original record supports loose coupling while internal data models evolve independently. section 17.1
Immutability changes how data is read and investigated:
- Treat entries as an ordered history: older entries precede newer ones, and new entries are written at the end. section 4.1.2
- Represent corrections or later facts as additional information rather than silently rewriting an earlier entry. section 4.1.2
- Use the history to investigate failures or recover an earlier state by replaying entries up to a chosen point. section 4.1.2
An event exchanged between services
A service publishes outside data describing a change. Other services may already have consumed it, so the record remains available as created instead of being altered or deleted. Each service can maintain an internal representation suited to its own needs while sharing a stable history of exchanged data. section 17.1
Figure 4.1 A log is a sequential list where we add elements at the end and read them from a specific position (offset). For example, we read from offset 0, then choose to read from offset 4, and so on.
The sequential-log diagram shows immutable entries being added at the end and read from selected positions identified by offsets. section 4.1.2
