5 ms·

It's not practical. That's why all the arguments for it involve overstating and hyperbole. The results speak for themselves. It's shit.

• runeks 5y ago
  The question is whether it’s not practical because it hasn’t received the three decades of engineering that relational databases have, or because it’s broken in theory.
  • cuddlecake 5y ago
    I think, for one given moment in time, Event Sourcing is the hottest thing you can have. Evolution is where the trouble's brewing. You add a column to a table with maybe a default value, all is good. You add a property to an event's payload, you suddenly have to deal with versioning. Event Sourcing with its current ecosystem and frameworks mainly add technical complexity with very little added clarity of business.
  • codeflo 5y ago
    Modern relational databases are marvels of engineering. But I don't think they would have gotten off the ground if they had needed those three decades to be practical at all.
• vegai_ 5y ago
  Two examples of systems that use a variant of event sourcing: - relational database systems (their journals and async replication in particular) - git Perhaps not so shit. Perhaps a bit practical. It's just a bad fit for some problems and architectologists like to say it's good for everything for obvious reasons. And it's should be pretty obvious that architecture doesn't matter at all if it's implemented poorly.
  • codeflo 5y ago
    We have to be very precise here I think. Git doesn't really store file changes as events, rather, it's a long chain of state snapshots, in something like a persistent data structure. Sure, the history is all there, but so is the current state in its most efficient form. DB transaction logs might be considered event sourcing by some definition, but their use is very different. It's purely a technical trick. As a consequence, logs are truncated as often as possible/reasonable, and you never rerun the transaction log from time zero. Very different from the event sourcing idea to keep events as long as possible.
    • dtech 5y ago
      Event sourcing with snapshotting and deleting old events - like DB transaction logs - is still event sourcing. In fact I'd say it's the only way ES makes practical sense.
    • kephasp 5y ago
      ES is always a technical trick. It's a way to store data, it's unrelated to the business domain…
    • vegai_ 5y ago
      I believe ES allows taking snapshots (they call them projections, perhaps?) and removing all logs before the snapshot, which I think is kinda what dbs do?
    • antod 5y ago
      yeah, describing git as a stream of change events sounds more like the way svn or mercurial worked than git.
  • _3u10 5y ago
    Here's the key, all the systems in which event sourcing works have clear immutable definitions of what an event does / means. eg. Git ALWAYS applies a commit in a consistent way (and where it doesn't it's a disaster) eg. If you modify the transaction replay code from one version to the next of a DB, it creates a mess. (and why many databases won't replay transactions from previous versions, or even boot at all, see Postgres) The problem with event sourcing is that the same bad practices that came from the CRUD system are recreated using events, which makes the system inherently worse because now the state of your system is unstable, instead of just the manner in which you got to the current state. Imagine if everytime your rebooted your Postgresql cluster and it replayed Postgres 7 transaction logs, even though your running on Postgres 13, and generated an objectively different state, except, now your using CI and every commit from every developer will boot your system into a different state. Also, your database now takes 2 months to start as every transaction gets replayed. Take rails db migrations for example, the best practice is, every 6 months or so, to just dump the schema from production, create one large initial "migration" and add migrations from there, because eventually they become desynced, and you can't cleanly replay your migrations into a schema that mirrors prod. If you are extremely careful, and follow a bunch of best practices you can, but in the general case it costs less to just dump schemas.
• rswail 5y ago
  That's bullshit. I've deployed a large CQRS/ES system that processes hundreds of thousands of business events each day. The entities/aggregates have clearly defined state machines and the commands/events that change their state are clearly documented and simple. The system is easy to understand, the business people understand it because we used their words to describe it. We were able to model it and workshop it with them by literally having them each take on the role of one of the aggregates and pass paper "commands" and "events" between each other. CQRS/ES is actually the way the world works. If you can't imagine a bunch of bureaucrats from Brazil, all sitting in a large room, passing files and paper forms between each other, then you're not understanding the actual work.
• zenron 5y ago
  ES is practical if your use case supports it. I think you only need to look at Citibank's success post 2008 banking crisis to see the successes they've had as a company. When their developers were touring the No Fluff Just Stuff events in 2015-2016 showing their work and how much they were giving back to the projects they were using really puts a stick in your wheel. Financial systems can really take advantage of it. Your post is hyperbole.