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

Event Sourcing in Go: From Zero to Production

skoredin.pro

Post reply on HN
Print view View original

51–55 of 55 posts

Re: Event Sourcing in Go: From Zero to Production

#51

Post by anthonylevine »

simonw wrote: post #44
anthonylevine wrote: post #34

Earlier quoted context omitted.

I think having constantly changing product requirements would certainly make it difficult, but that makes all development more difficult. In fact, I think most complexity I create or encounter is in response to trying to future-proof stuff I know will change. I'm in healthcare. And it changes CONSTANTLY. Like, enormous, foundation changes yearly. But that doesn't mean there aren't portions of that domain that could b…

Thanks, this is a great comment. Love the observation that event sourcing only makes sense for parts of a system. Could be that some of the bad experiences we hear about are from people applying it to fields like content management (I've been tempted to try it there) or applying it to whole systems rather than individual parts.

No problem and likewise. Conversations like this are great because they constantly make me re-evaluate what I think/say and often times I'll come out of it with a different opinion.

> Could be that some of the bad experiences we hear about are from people applying it to fields like content management (I've been tempted to try it there) or applying it to whole systems rather than individual parts

Amen. And I think what most people miss is that it's really hard to do for domains you're just learning about. And I don't blame people for feeling frustrated.

Re: Event Sourcing in Go: From Zero to Production

#52

Post by anthonylevine »

mrkeen wrote: post #46
simonw wrote: post #29

Earlier quoted context omitted.

I've not run an event sourcing system in production myself. This thread appears to have stories from several people who have though, and have credible criticisms: https://news.ycombinator.com/item?id=45962656#46014546 https://news.ycombinator.com/item?id=45962656#46013851 https://news.ycombinator.com/item?id=45962656#46014050 What's your response to the common theme that event sourcing systems are difficult to mainta…

> What's your response to the common theme that event sourcing systems are difficult to maintain in the face of constantly changing product requirements? I've been on an ES team at my current job, and switched to a CRUD monolith. And to be blunt, the CRUD guys just don't know that they're wrong - not their opinion about ES - but that the data itself is wrong. Their system has evaluated 2+2=5, and with no way to see t…

> It's inefficient because it's stringy data in an SQL database, but I look forward to support tickets because i don't have to "debug". I just read the events, and have the evidence to back up that the customer is wrong and the system is right.

I think one of the draws of ES is that it feels like the ultimate way to store stuff. The ability to pinpoint exact actions in time and then use that data to create different projections is super cool to me.

Re: Event Sourcing in Go: From Zero to Production

#54

Post by [deleted] »

mrkeen wrote: post #50
liampulles wrote: post #28

If you are considering event sourcing, run an event/audit log for a while and see if that does not get you most of the way there. You get similar levels of historical insight, with the disadvantage that to replay things you might need to put a little CLI or script together to infer commands out of the audit log (which if you do a lot, you can make a little library to make building those one off tools quite simple - I…

I've done this. We have a customer whom we bill for feature X. Does he actually have feature X or are we billing him for nothing? With ES: We see his Subscriptions and Cancellations and know if he has feature X. Without ES: We don't know if he subscribed or cancelled. With audit log: We almost know whether he subscribed or cancelled.

[deleted]

Re: Event Sourcing in Go: From Zero to Production

#55

Post by azkalam »

andersmurphy wrote: post #32
zknill wrote: post #18

Earlier quoted context omitted.

I think you might struggle to "scale the read and write sides independently". It's a real stretch to be describing a postgres view as CQRS

Sqlite can scale CQRS to 100000 events per second on a relatively small VPS. That's 10x what the author achieves with postgres. You can scale them independently in that you can control the rate at which your views are read and the batch size of your updates. The whole big win wirh CQRS is it allows for very efficient batching.

But only one server can access each SQLite at a time?
Post reply on HN