The ledger that never forgets
Most databases forget. A row recording an account balance says nothing about how that balance came to be — last week’s deposit, the reversed charge, the wire transfer that arrived in two batches. The row is current state. The history is gone.
In December 2005, Martin Fowler proposed a different approach, illustrated with ships: if you want to know where a vessel is, you don’t need a row labeled “current position.” You need a log of every port it visited. Current state is just events replayed forward — and if you store the events, you can reconstruct any state, past or present, at will. Fowler called this “event sourcing,” and set it aside as possibly too obvious to be interesting.
The rest of the industry took a decade to disagree.
In 2009, a software architect named Greg Young was working on trading systems where the rules for reading an account position and the rules for writing a trade order were so different they barely belonged in the same codebase. He started calling his approach Command Query Responsibility Segregation — CQRS — building on Bertrand Meyer’s 1988 principle that a method should either change state or return a value, but never both. The term landed in a 2010 blog post with the title “CQRS, Task Based UIs, Event Sourcing agh!” — the giveaway of a man who thought he was stating the obvious. He was not. By July 2011, Fowler had written a formal description and included a warning almost no one heeded: for most systems, CQRS adds risky complexity.
Pair CQRS with event sourcing and you had a complete answer to the thorniest question in distributed computing: how do you keep state coherent across services that cannot share a database? You don’t share state. You share events. Each service emits what happened; the others subscribe and update accordingly. The log becomes the single source of truth.
In 2012, Young released EventStoreDB, a purpose-built database for event-sourced systems. In December 2013, Jay Kreps at LinkedIn published “The Log: What Every Software Engineer Should Know About Real-Time Data’s Unifying Abstraction” — arguing that the append-only log was the organizing principle of distributed systems, and that Apache Kafka, open-sourced from LinkedIn in 2011, was its most concrete expression. Docker had shipped in March 2013. Kubernetes arrived in 2014. As teams split monoliths into microservices, each owning its own database, the problem Fowler and Young had already solved on paper became urgent and universal. By 2015, event-driven architecture had moved from the vocabulary of trading desks and domain-driven design into the standard toolkit of any engineering team building at scale.
The shift was larger than the tooling. A traditional database records what is. An event-sourced system records what happened. Current state becomes a derived view; the authority is the sequence of events that produced it — preserved, replayable, auditable. Young needed that for regulators. The microservices era needed it because distributed systems break, and when they break, you want the log.
Merchants in 14th-century Florence had found the same answer. Every transaction written down, nothing erased, the ledger the final word. The software engineers arrived at the same conclusion, roughly six hundred years later.
Sources
- Event Sourcing — Martin Fowler (2005) — the December 2005 origin of the term; the ship-tracking example; the capabilities of rebuild, temporal query, and replay
- CQRS — Martin Fowler (2011) — July 2011 documentation of Greg Young’s CQRS pattern; the warning about added complexity for most systems
- Command Query Responsibility Segregation — Wikipedia — Greg Young’s 2010 coinage, Bertrand Meyer’s CQS antecedent, relationship to domain-driven design and event sourcing
- The Log — Jay Kreps, LinkedIn Engineering (2013) — December 2013 essay connecting Kafka and the append-only log as the unifying abstraction for distributed systems