Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Event Sourcing (2017)

arkwright.github.io

Post reply on HN
Print view View original

71–80 of 80 posts

Re: Event Sourcing (2017)

#71

Post by Mouse47 »

ekvilibrist wrote: post #37
Yuioup wrote: post #22

Earlier quoted context omitted.

Thank you for this. I've been warning people off Event Sourcing for a while now. The architecture is the most convoluted, pretentious, redundant and downright soul-crushing. If you see Event Sourcing anywhere, run away. Run far, far away.

I've only suggested event sourcing once, and that was for keeping physical warehouse inventory synced with orders. I.e. instead of having like a database table with a "available product count", we made a view that calculated "product stock minus pending orders" on the fly at any given timestamp. Very efficient, simple and easy to debug. But as a general system architectural pattern it does seem to create more issues…

Good approach. Much of software engineering is applying principals like event sourcing judiciously. Why does the whole system need to be in one architecture?

Re: Event Sourcing (2017)

#72

Post by lukev »

seer wrote: post #51
lukev wrote: post #20

A word of caution for anyone considering an event-sourced architecture. I was on a large government project where the decision was made to use event sourcing, and it was disastrous. It ended up being a big contributor to several years of time and cost overruns. The reason is that for event sourcing to work, you have to have a pretty good idea of your application's requirements up front. It's simply not conducive to a…

A way to deal with it that I've seen to work with Kafka is to make your messages not last very long (say about a week) and make them explicitly idempotent. So an "old" message being run would not affect the app negatively. And then you make every producer of messages able to reproduce all the messages it knows about. So if you have a new service and need historical data, you ask all of your dependencies to resend the…

Datomic is interesting in the context of event sourcing, because it can be thought of as a highly generalized event store system itself, with each database transaction being an event.

Re: Event Sourcing (2017)

#73

Post by lukev »

andreareina wrote: post #25
lukev wrote: post #20

A word of caution for anyone considering an event-sourced architecture. I was on a large government project where the decision was made to use event sourcing, and it was disastrous. It ended up being a big contributor to several years of time and cost overruns. The reason is that for event sourcing to work, you have to have a pretty good idea of your application's requirements up front. It's simply not conducive to a…

I'd love to read about the original assumptions -> original design -> revised assumptions -> design invalidations if you care (and are able) to write.

Unfortunately it was on a consulting project with an NDA.

Re: Event Sourcing (2017)

#74

Post by lukev »

AndrewKemendo wrote: post #29
lukev wrote: post #20

A word of caution for anyone considering an event-sourced architecture. I was on a large government project where the decision was made to use event sourcing, and it was disastrous. It ended up being a big contributor to several years of time and cost overruns. The reason is that for event sourcing to work, you have to have a pretty good idea of your application's requirements up front. It's simply not conducive to a…

I mean that conclusion is true of basically every complex system. That's the whole point of hacking together an MVP first, to see what really matters. However it's silly IMO to use that criteria as an example of why not to do event driven architecture. It's well understood in the eda community that you generally don't start with streaming systems unless you know you need it from the start.

In this case it was shiny object syndrome on the part of a few early architects.

The whole project could have been a Rails app.

The lesson is less about event sourcing, and more about picking architectures in light of business needs rather than trying to be fancy.

Re: Event Sourcing (2017)

#75

Post by anaganisk »

rodocite wrote: post #10

I think the article is too scattered and doesn't actually discuss how event sourcing works. Key concepts are missing. People who actually want to learn it will end up getting even more confused or misguided-- which seems like the trend with this thing. Excuse the list formatting. I don't post here that much. Just scroll if the list item is cut off. TLDR; Use Redux-Saga-- it matches all the bird-eye view event sourcin…

this must be up

Re: Event Sourcing (2017)

#76

Post by richardARPANET »

GordonS wrote: post #49
richardARPANET wrote: post #46

Earlier quoted context omitted.

+1. My company consulted on a project where the use of event sourcing was THE reason the entire project (and the client company) failed. This was the event sourcing library being used for that https://github.com/johnbywater/eventsourcing

Was the actual library used a significant part of the problem, or was it the pattern of event sourcing itself that wasn't a good fit?

Both. The library was slow and corrupted data and they were using regular databases along with the event-sourced stuff. That would never work, the whole system would have needed to be event sourced for it to have any chance of working.

It was essentially a CRUD app with the need for history of changes (for a few tables), SQL was the correct way to do it.

Re: Event Sourcing (2017)

#77

Post by TheCoelacanth »

andreareina wrote: post #26
codebje wrote: post #19

Earlier quoted context omitted.

Your event log should IMO be nominally immutable rather than actually immutable. You should feel free to take actions such as expunging private or sensitive data as appropriate. Keep the events, but rewrite them to contain only the desired data. Trivial to implement, and simple. I'd only worry about stuff like crypto-erasure if you physically cannot alter the past, such as if you have a requirement for non-repudiatio…

I think cases where you cannot alter the past (or can only do so with difficulty) are fairly common; backups will easily tend to fall in that category.

Backups have the same GDPR concerns regardless of whether you are doing event sourcing or not.

Re: Event Sourcing (2017)

#78

Post by [deleted] »

GordonS wrote: post #49
richardARPANET wrote: post #46

Earlier quoted context omitted.

+1. My company consulted on a project where the use of event sourcing was THE reason the entire project (and the client company) failed. This was the event sourcing library being used for that https://github.com/johnbywater/eventsourcing

Was the actual library used a significant part of the problem, or was it the pattern of event sourcing itself that wasn't a good fit?

[deleted]

Re: Event Sourcing (2017)

#79

Post by jbywater »

GordonS wrote: post #49
richardARPANET wrote: post #46

Earlier quoted context omitted.

+1. My company consulted on a project where the use of event sourcing was THE reason the entire project (and the client company) failed. This was the event sourcing library being used for that https://github.com/johnbywater/eventsourcing

Was the actual library used a significant part of the problem, or was it the pattern of event sourcing itself that wasn't a good fit?

Neither. If Richard's statements were facts they would violate his NDAs. In fact, these statements are falsehoods, and seem designed only to cause damage. Also, he's referring to 2016!

The only "problem" is that in 2016 I was physically assaulted at work, Richard had to leave work soon after, and has been denigrating my work since then. For example, here's a post from 2016, where it appears he had a multi-account conversation with himself: https://news.ycombinator.com/item?id=13129798

Three years later, he's still unable to get over it and move on. This feels like a kind of twisted sexual investment, so I have chosen not to reply.

The Python eventsourcing library is excellent, and event sourcing is a great idea. The library is open source, so if Richard had discovered a bug that caused "corrupt data", he could have raised an issue on GitHub. But there hasn't been such a bug, and no such issue has been raised. Everybody can look through the mere 56 closed issues in the entire history of this successful project to see how many "corrupted data" bugs there have been (zero). https://github.com/johnbywater/eventsourcing/issues

The library is being used successfully in production. Some users have data stores with millions of stored domain events, and the library still works very fast. I didn't hear about anybody having billions of events yet, but I wouldn't expect much difference in performance, so long as the infrastructure has sufficient volume.

In case the wrong impression is created by listening to Richard's rubbish, SQL and event sourcing aren't somehow incompatible. Event sourcing isn't somehow the opposite of "regular databases". The library works very well with SQL databases, through both Django ORM and SQLAlchemy. It also works with NoSQL databases.

If you see posts like this in future, please ignore them, it's just fake news. My understanding is that Richard has diagnosed mental problems. But perhaps there's a kind of nominative determinism from the shortened version of his name? I don't know. At any rate, I've been keeping a log of these occasions, in case I need to call the police again.

Re: Event Sourcing (2017)

#80

Post by legulere »

inopinatus wrote: post #28
Yuioup wrote: post #22

Earlier quoted context omitted.

Thank you for this. I've been warning people off Event Sourcing for a while now. The architecture is the most convoluted, pretentious, redundant and downright soul-crushing. If you see Event Sourcing anywhere, run away. Run far, far away.

Some of worlds most useful and powerful data structures are the projection of an event log. The tables of a RDBMS, the balanced writes of a SSD, and even the classic: double-entry book-keeping. Even the data stream of a TCP connection is a projection of events, which is why (and how) we can reconstruct them by replaying captured segments. So just because there are some lousy executions of a general architecture, does…

You could say the same about e.g. lock free algorithms. If you work on them you are usually just playing with some cool technology instead of solving the business requirements.
Post reply on HN