Why Are People into Event Sourcing?
Event sourcing isn&#x27;t nearly as common knowledge among new programmers as the CRUD-one-row-per-entity pattern, and it really should be. I liken it to introducing version control for your data; when immutable updates are your canonical source, no matter how much the system behind them changes, or the business requirements change, and no matter how many teams are deriving different things from them in parallel, they can all work off of the same data and &quot;merge&quot; their efforts together.<p>The one downside is that shifting your business logic to read-time means that you need to have very efficient ways of accessing and memoizing derived data. For some applications, this can be as simple as having the correct database indices over your WhateverUpdates tables, fetching all updates into memory and merging on each request. For others, you&#x27;ll need to have a real-time stream processing pipeline to preemptively get your derived data into the right shape into a cache. And those are more moving parts than your typical monolith app, but the<p>One benefit to actually using event sourcing with a stream processing system is that, in many cases, it can be the most effective way to scale both traffic capacity and organizational bandwidth, much in the same way that individually scalable microservices can (and fully compatible with that approach!). Martin Kleppman at Confluent (a LinkedIn spinoff creating and consulting on stream processing systems) writes some great and highly-approachable articles about this. Highly recommended reading.<p><a href="http:&#x2F;&#x2F;www.confluent.io&#x2F;blog&#x2F;making-sense-of-stream-processing&#x2F;" rel="nofollow">http:&#x2F;&#x2F;www.confluent.io&#x2F;blog&#x2F;making-sense-of-stream-processi...</a><p><a href="http:&#x2F;&#x2F;www.confluent.io&#x2F;blog&#x2F;turning-the-database-inside-out-with-apache-samza&#x2F;" rel="nofollow">http:&#x2F;&#x2F;www.confluent.io&#x2F;blog&#x2F;turning-the-database-inside-out...</a>