A couple of months back, I read this article explaining that event streaming != event sourcing
The understanding of these two has eluded me for years.
I first heard of it back in 2017 when my mentor was introducing DDD to me. In my head, I oversimplified it as a pub-sub pattern but with flair 😆
That mental model remained useful as I worked on a few event-driven applications. Some utilized it on the application tier while some applied it as a way to orchestrate microservices.
The “leitmotiv” article cited by the article above is something I’ve seen several times, and one I find myself agreeing with when I was working with architectures employing such. It is fancy. It seems elegant but it also introduces a lot of drawbacks. Add to that, it’s also a bit unintuitive versus a simple “let me handle that request, process it, write it to the database, here’s your response, and voila we’re done” -- very CRUD-y I suppose.
But it turns out, I was conflating the two terms 🤦
Looks like I’ve never tried event sourcing yet, and it's probably something I won’t be able to try anytime soon.
I’m a little skeptical about how replaying the events will scale. Granted, I didn’t read the additional articles the author shared (he has one for modelling event sourcing streams and keeping them short).
How about you? Have you tried event sourcing before? How was it?
And if not, will you ever try event sourcing?
Top comments (0)