Event Sourcing Is Hard (2019)
I&#x27;ve worked with several event sourcing systems and was even seduced into implementing one out of sheer hubris once. These problems are ever present in every ES project I&#x27;ve had the misfortune of coming into contact with. It doesn&#x27;t even mention the worst part that comes afterwards, when you realize after all of that pain that it is only used by a single person in the company to generate a noncritical report comparing a meaningless KPI that could have been manually done in four hours by a different intern every quarter. By the time the tooling is up and running enough to make a stable system, no one will trust it enough to use ES&#x27;s landmark features except for a few developers still coming off the koolaid.<p>99% of the time when ES sounds like a good idea, the answer is to just use Postgres. Use wal2json and subscribe to the WAL stream - if you really need time travel or audit logs or whatever, they&#x27;ll be much cheaper to implement using WAL. If you need something more enterprisey to sell to the VP-suite, use Debezium.<p>Event sourcing sounds so <i>awesome</i> in theory and it is used to great effect in many demanding applications (like Postgres! WAL = event sourcing with fewer steps) but it&#x27;s just too complex for non-infrastructure software without resources measured in the 10s or 100s of man years.