https://chriskiehl.com/article/event-sourcing-is-hard
https://news.ycombinator.com/item?id=19072850
Software changes, requirements change, focuses shift. Those immutable "facts," along with your ability to process them, won't last as long as you expect.
We made it about a month before a shift in focus caused us to hit our first "oh, so these events are no longer relevant, at all?" situation. Once you hit this point, you've got a decision to make: what to do with the irrelevant / wrong / outdated events.
Do you keep the now deprecated events in the ledger, but "cast" them up to new events (or no-ops) during materialization, or do you rewrite the ledger itself to remove/cast the old events? The best practices in this area are often debated.
blog-post-event-sourcing-drawbacks#audit-log-too-chatty1The audit log is often too chatty for direct use. This one is obviously very business / use case dependent, but having a full low-level audit log of every action in the application was often more of a hindrance than a help. Meaning, most of it ends up being pure noise that actually needs filtered out, both by end users, and by consuming sub-systems. All of those transient "Bob renamed field x to y" are seldom of interest. If you're showing the audit log to an end user, more often than not, discrete logical states are of far more value than transient intermediates. So, the "free audit log" actually turns into "tedious projection writing." For downstream systems, this chattiness causes similar coordination woes. "When should I actually run?" and "should I care about event X?" was a common question during design meetings. It's all in the class of problems that require either Process Managers or the introduction of queues to solve. blog-post-event-sourcing-drawbacks#audit-log-too-chatty1
blog-post-event-sourcing-drawbacks#materialization-lagOnce your data grows to the point where you can no longer materialize from the ledger in a reasonable amount of time, you'll be forced to offload the reads to your materialized projections. And with this step comes materialization lag and the loss of read-after-write consistency. blog-post-event-sourcing-drawbacks#materialization-lag
hacker-news-comment-bitemporal