2 ms·

I've worked with event driven architecture and it's always been a nightmare. Essentially, you're reinventing a commit log, about 1/4 of a really shitty custom d

I've worked with event driven architecture and it's always been a nightmare. Essentially, you're reinventing a commit log, about 1/4 of a really shitty custom database. Once you have aggregates you've basically gone full wheel. Add to that, the fact that normal RPC is "forbidden", so you end up with like 10 copies of each aggregate across various services. The killer feature is "replays", but trust me, after storing every state change for even a few weeks those replays are going to start taking hours if not days. And your services are all down while they happen. Pretty soon you start understanding the wisdom of databases not keeping commit logs around forever. If you value your sanity wait this one out

Terr_ 8y ago
I think it helps to distinguish between (A) event sourcing and (B) systems that emit events as a coordination and communication mechanism only. In the first case, you're able to do those replays but you also have the pain of somehow controlling the evolution of that system over time, as event-definitions and the consuming code behavior changes constantly. I think the second case has a lot more "easy wins" and is a better fit for most systems that do not require exhaustive auditing. You might keep all of the events around in a durable store, but they're more like hieroglyphics in a museum than a library book that is constantly retranslated.