6 ms·

I would like to see answers to the question: why move from Crud to event sourcing. Because I have seen at least 5 moderate projects trying to integrate ES. The

I would like to see answers to the question: why move from Crud to event sourcing. Because I have seen at least 5 moderate projects trying to integrate ES. They all failed in the sense that either people didn't understand the code anymore, huge integration times, performance issues and even complete project cancellation because of all people walking away

Flankk 5y ago
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.
blowski 5y ago
I work on a bog standard ERP that was originally CRUD, but a whole module was refactored to event sourcing so clients could have a log and rollback. A couple of months back, a QA review reported a bug - the log system didn’t work. Turns out it’s never worked. Nobody has ever done a rollback either.
- classabove 5y ago
  this is absolutely terrifying
  - fullstackchris 5y ago
    not if nobody uses it ¯\_(ツ)_/¯
    - nickkell 5y ago
      It's similar to database backups - hopefully you'll never need it, but at some point you might. At that point you'd hope your data was intact
      - blowski 5y ago
        The cost of doing a database backup is usually much lower than the cost of doing event sourcing.
- square_usual 5y ago
  Oh yeah, I've run into similar situations so many times. A critical piece of functionality was overnegineered and shipped, only months later did we find out that it never worked, and nobody found out because nobody used it.
- shironandon 5y ago
  Was working on a client's stack and this one critical piece using ES (written by "experts" who had since left the company) was throwing an error every week at 2 AM triggering alerts and chaos. After investigation I found nobody understood what it was doing or why. I thereby found the safest approach was to delete the ES implementation. After that everything worked and everyone was happy.
lmm 5y ago
Prevent lost writes from when two people read-modify-write at the same time. Be able to answer questions like "how did this end up like this" or "what happened to the change I made on xx/yy". Easier sharding, better performance, and avoiding deadlocks, because you're not worrying about database-level transactions any more. Much easier data migrations that you can do in a gradual, rollbackable way. Clear data provenance that lets you know how to resolve inconsistencies. Easier backups. Smoother relationship between live data and analytics/reporting.
- holoduke 5y ago
  Could you elaborate how you solve transaction, double writes , deadlocks. I mean the consumers do still process messages in parallel right? Or do you force a serial pipeline to avoid handling messages at the same time? I thought that EV is more about creating entire separate entities/codebase which have zero dependencies.
  - randolorian 5y ago
    A proper event storage solution will have optimistic concurrency built in.
  - lmm 5y ago
    > I mean the consumers do still process messages in parallel right? Or do you force a serial pipeline to avoid handling messages at the same time? Generally I follow the Kafka approach of, essentially, shards that are each processed serially. So unrelated messages may be processed out of order, but related messages will be processed serially. If you don't have a good enough key, or you need to join two streams, then you have to use CRDTs or equivalent. This can be hard, and you will have bugs, but since you retain the original events, you can always fix things up and recover the correct data, whereas when you get an SQL datastore into an inconsistent state you're generally SOL.
tlarkworthy 5y ago
not sure about event sourcing, but replicating your state immutably on write can save your bacon if there is a bug. I try to skip the D and make the U fork in CRUD for systems where the data is very valuable. classic event sourcing require playing your events in order to calculate state. I think that's a complexity. Just do normal state computation but write it into a new timestamped row
JamesBarney 5y ago
Here's why I used event sourcing. We were modeling well dynamics. And to calculate interesting properties of the well we needed sensor data, the previous state of the well, and a model of the well built by a petroleum engineer. Unfortunately the model of the well wasn't always up to date (pump was replaced, etc..), so we needed to be able to replay all of the sensor data into the well when a model was retroactively changed. Event sourcing was such an easy pick because our events were very simple (15 fields of data) and our replay requirement was a showstopper.
- y4mi 5y ago
  it sounds pretty straightforward to implement with basic crud too, though. you'd just need an inserted timestamp field so that you can rerun the analysis with where inserted >= the_date order by inserted
  - nivertech 5y ago
    I think GP mixing up Stream Processing with Event Sourcing [1]. Event Sourcing is usually used in complex business domains, Stream Processing in simple domains, but with large amounts of data (i.e. IIoT). if you use a timeseries databases like kdb+/q, TimescaleDB, InfluxDB, QuestDB, etc., you don't even need to order by the insertion timestamp. Unlike RDBMS/SQL where rows/tuples are unordered, in timeseries databases they're usually ordered by the insertion time, more similar to dataframes than to SQL tables. -- [1] Martin Kleppmann — Event Sourcing and Stream Processing at Scale https://www.youtube.com/watch?v=avi-TZI9t2I https://www.youtube.com/watch?v=avi-TZI9t2I
dgb23 5y ago
I have never implemented ES, although it seems to be useful to have the most simple version of it in place: just a queryable log of versioned events and the ability to replay it. But if you have the luxury to do consistent CRUD with a relational/graph, ACID database, then a temporal data model might give you much more leverage. Essentially you think of your records as bookkeeping entries and go from there. You retain the ability to do ad-hoc relational queries, while not having to build core database functionality yourself.
discreteevent 5y ago
I worked on a system years ago before event sourcing was even a term. We built the system on top of a relational database but stored every change and had a generic schema. We did this because we specifically had requirements where we needed to be able to quickly generate diffs between states of the system (differences in time and differences in version). So it was a natural solution to this problem and the benefits for us outweighed the costs. Of course we only used this approach for the part of our system that had these requirements.

Flankk 5y ago

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.

blowski 5y ago

I work on a bog standard ERP that was originally CRUD, but a whole module was refactored to event sourcing so clients could have a log and rollback. A couple of months back, a QA review reported a bug - the log system didn’t work. Turns out it’s never worked. Nobody has ever done a rollback either.

classabove 5y ago
this is absolutely terrifying
- fullstackchris 5y ago
  not if nobody uses it ¯\_(ツ)_/¯
  - nickkell 5y ago
    It's similar to database backups - hopefully you'll never need it, but at some point you might. At that point you'd hope your data was intact
    - blowski 5y ago
      The cost of doing a database backup is usually much lower than the cost of doing event sourcing.
square_usual 5y ago
Oh yeah, I've run into similar situations so many times. A critical piece of functionality was overnegineered and shipped, only months later did we find out that it never worked, and nobody found out because nobody used it.
shironandon 5y ago
Was working on a client's stack and this one critical piece using ES (written by "experts" who had since left the company) was throwing an error every week at 2 AM triggering alerts and chaos. After investigation I found nobody understood what it was doing or why. I thereby found the safest approach was to delete the ES implementation. After that everything worked and everyone was happy.

lmm 5y ago

Prevent lost writes from when two people read-modify-write at the same time. Be able to answer questions like "how did this end up like this" or "what happened to the change I made on xx/yy". Easier sharding, better performance, and avoiding deadlocks, because you're not worrying about database-level transactions any more. Much easier data migrations that you can do in a gradual, rollbackable way. Clear data provenance that lets you know how to resolve inconsistencies. Easier backups. Smoother relationship between live data and analytics/reporting.

holoduke 5y ago
Could you elaborate how you solve transaction, double writes , deadlocks. I mean the consumers do still process messages in parallel right? Or do you force a serial pipeline to avoid handling messages at the same time? I thought that EV is more about creating entire separate entities/codebase which have zero dependencies.
- randolorian 5y ago
  A proper event storage solution will have optimistic concurrency built in.
- lmm 5y ago
  > I mean the consumers do still process messages in parallel right? Or do you force a serial pipeline to avoid handling messages at the same time? Generally I follow the Kafka approach of, essentially, shards that are each processed serially. So unrelated messages may be processed out of order, but related messages will be processed serially. If you don't have a good enough key, or you need to join two streams, then you have to use CRDTs or equivalent. This can be hard, and you will have bugs, but since you retain the original events, you can always fix things up and recover the correct data, whereas when you get an SQL datastore into an inconsistent state you're generally SOL.

tlarkworthy 5y ago

not sure about event sourcing, but replicating your state immutably on write can save your bacon if there is a bug. I try to skip the D and make the U fork in CRUD for systems where the data is very valuable. classic event sourcing require playing your events in order to calculate state. I think that's a complexity. Just do normal state computation but write it into a new timestamped row

JamesBarney 5y ago

Here's why I used event sourcing. We were modeling well dynamics. And to calculate interesting properties of the well we needed sensor data, the previous state of the well, and a model of the well built by a petroleum engineer. Unfortunately the model of the well wasn't always up to date (pump was replaced, etc..), so we needed to be able to replay all of the sensor data into the well when a model was retroactively changed. Event sourcing was such an easy pick because our events were very simple (15 fields of data) and our replay requirement was a showstopper.

y4mi 5y ago
it sounds pretty straightforward to implement with basic crud too, though. you'd just need an inserted timestamp field so that you can rerun the analysis with where inserted >= the_date order by inserted
- nivertech 5y ago
  I think GP mixing up Stream Processing with Event Sourcing [1]. Event Sourcing is usually used in complex business domains, Stream Processing in simple domains, but with large amounts of data (i.e. IIoT). if you use a timeseries databases like kdb+/q, TimescaleDB, InfluxDB, QuestDB, etc., you don't even need to order by the insertion timestamp. Unlike RDBMS/SQL where rows/tuples are unordered, in timeseries databases they're usually ordered by the insertion time, more similar to dataframes than to SQL tables. -- [1] Martin Kleppmann — Event Sourcing and Stream Processing at Scale https://www.youtube.com/watch?v=avi-TZI9t2I https://www.youtube.com/watch?v=avi-TZI9t2I

dgb23 5y ago

I have never implemented ES, although it seems to be useful to have the most simple version of it in place: just a queryable log of versioned events and the ability to replay it. But if you have the luxury to do consistent CRUD with a relational/graph, ACID database, then a temporal data model might give you much more leverage. Essentially you think of your records as bookkeeping entries and go from there. You retain the ability to do ad-hoc relational queries, while not having to build core database functionality yourself.

discreteevent 5y ago

I worked on a system years ago before event sourcing was even a term. We built the system on top of a relational database but stored every change and had a generic schema. We did this because we specifically had requirements where we needed to be able to quickly generate diffs between states of the system (differences in time and differences in version). So it was a natural solution to this problem and the benefits for us outweighed the costs. Of course we only used this approach for the part of our system that had these requirements.