Event Sourcing
Storing every change that ever happened, instead of only the current state, so the current state becomes a derived view.
Event sourcing stores the full sequence of events that happened to a piece of data — OrderPlaced, OrderShipped, OrderRefunded — as the source of truth, rather than storing only the current row and overwriting it on each change. Current state is derived by replaying the events in order; it isn't stored independently at all, or if it is, it's a cache that could in principle be rebuilt from the log.
This inverts the usual relationship between a database's current state and its history. A conventional table with an updated_at column keeps the present and discards the past — the row before the last update is simply gone. Event sourcing keeps everything and treats the present as one particular view computed from it, which makes an audit log, a point-in-time reconstruction, or a "why does this order look like this" investigation a query against existing data rather than something that had to be anticipated and logged separately in advance.
The cost is that querying "current state" now requires either replaying potentially very long event histories, or maintaining a read model — a materialized, denormalized projection kept in sync with the event log — which is exactly the split that CQRS (command query responsibility segregation) names: writes go to the event log, reads go to a separately maintained projection built for the query pattern that needs it. Change Data Capture is the more common on-ramp to this idea in practice — it turns an ordinary database's own write history into the same kind of event stream, without requiring the whole system to be designed around events from the start.
See also8
Denormalization
Deliberately duplicating data to make reads faster, trading update complexity for query simplicity.
Data & Content7 connections
Message Queue
A buffer that decouples a producer from a consumer in time, so neither has to be up, fast, or reachable at the same moment.
Data & Content14 connections
Write-Ahead Logging
Recording the intent of a change durably before applying it, so a crash can be recovered.
Computation & Algorithms20 connections
State Management
How a front-end application keeps track of the data that changes as people use it, and decides where each piece lives, from local component state to global stores to server caches.
Web Platform12 connections
Soft Delete
Marking a record as deleted instead of removing it, which makes deletion reversible and auditable but leaks complexity into every query.
Data & Content11 connections
Persistent Data Structure
Data structures that preserve every previous version when changed, sharing unchanged parts between versions so "copying" is cheap.
Computation & Algorithms9 connections
Schema Evolution
Changing the shape of stored or transmitted data without breaking the old readers and writers that still expect the previous shape.
Data & Content9 connections
Timeline
Laying events out along a line in order of time, a form that seems obvious but was invented in the eighteenth century and still forces hard choices about scale, density, and what counts as an event.
Design & Interface4 connections
Linked from12
- Audit LogData & Content
An append-only record of who did what, to what, and when, kept to answer questions of accountability long after the fact, and built so that even its administrators can't quietly rewrite it.
- Change Data CaptureData & Content
Turning a database's own internal write log into a stream other systems can subscribe to, without touching the application.
- DenormalizationData & Content
Deliberately duplicating data to make reads faster, trading update complexity for query simplicity.
- Materialized ViewData & Content
The stored result of a query, kept as a table so that expensive reads become cheap, at the cost of keeping that result up to date.
- Message QueueData & Content
A buffer that decouples a producer from a consumer in time, so neither has to be up, fast, or reachable at the same moment.
- Persistent Data StructureComputation & Algorithms
Data structures that preserve every previous version when changed, sharing unchanged parts between versions so "copying" is cheap.
- Schema EvolutionData & Content
Changing the shape of stored or transmitted data without breaking the old readers and writers that still expect the previous shape.
- Soft DeleteData & Content
Marking a record as deleted instead of removing it, which makes deletion reversible and auditable but leaks complexity into every query.
- State ManagementWeb Platform
How a front-end application keeps track of the data that changes as people use it, and decides where each piece lives, from local component state to global stores to server caches.
- TimelineDesign & Interface
Laying events out along a line in order of time, a form that seems obvious but was invented in the eighteenth century and still forces hard choices about scale, density, and what counts as an event.
- Two-Phase CommitData & Content
A protocol for committing one transaction across multiple databases atomically, at the cost of blocking if the coordinator dies.
- UndoDesign & Interface
Letting people reverse what they just did, which makes interfaces safe to explore and usually beats asking "are you sure?" before every action.