Stream-Table Duality
The equivalence between a stream of changes and a table of current state, where each can be derived from the other.
The idea underneath most modern streaming architecture. A table is the accumulated result of a stream of change events. A stream is the sequence of changes between successive table states. Neither is more fundamental; they are two views of the same information.
This is not academic. It explains why a compacted log — retaining only the latest value per key — is a table, why materialised views can be maintained incrementally from a change stream, why CDC turns a database table back into the stream that produced it, and why event sourcing is a legitimate storage strategy rather than a curiosity.
The design leverage is that you can choose the representation that suits each consumer without choosing a system of record for each. One change stream can serve a search index, a cache, an analytical table and an operational read model, each materialising the same truth in the shape it needs.
The constraint that comes with it is ordering: the derivation is only correct if changes for a given key are applied in order, which is why partitioning by key is not a performance tuning choice but a correctness requirement.