A method for representing state of a system using immutable events over time that can be aggregated to derive state at a particular moment. This software architectural pattern has the advantage of replay-ability (events can be re-processed as needed), time travel debugging (view of state at a specific moment in time), and decoupling systems (event emitters separate from consumers and aggregations).
A real world examples is double entry bookkeeping. A software example is a shopping cart checkout flow.
Links to this note
-
Software Architectural Pattern
A way of organizing code and abstracting concepts to build a software system often with the goals of robustness, reliability, extensibility, performance, and correctness.
-
Games Don’t Generalize Well to a Client-Server Model
In video game programming it can be tempting to replicate a client server model similar to how websites work. This is generally a mistake because game state tends to be highly co-mingled between state and graphics. Attempting to cleanly separate the ‘backend’ game logic with ‘frontend’ visuals results in awkward boundaries between the two, which are still coupled, but in a way that requires more complicated code to manage (e.g. a message bus, event sourcing) and are probably less performant (e.g. passing json messages within a 33ms frame budget).