Event Sourcing in Go: From Zero to Production
skoredin.pro
Event Sourcing in Go: From Zero to Production
1–10 of 55 posts
Re: Event Sourcing in Go: From Zero to Production
#2I'm going to have a word with my ISP. It seems that sites SSL certificates has expired. That's not a good thing, but my ISP decided I'm an idiot and gave me a condescending message about accepting expired certificate - unacceptable in my book. VPN helped.
Too much dry code for my taste and not many remarks/explanations - that's not bad because for prose I'd recommend Martin's Fowler articles on Event processing, but _could be better_ ;-)
WRT to tech itself - personally I think Go is one of the best languages to go for Event Sourcing today (with Haskell maybe being second). I've been doing complexity analysis for ES in various languages and Go implementation was mostly free (due to Event being an interface and not a concrete structure).
Re: Event Sourcing in Go: From Zero to Production
#3How does event sourcing handle aggregates that may be larger than memory?
Re: Event Sourcing in Go: From Zero to Production
#4I'm going to have a word with my ISP. It seems that sites SSL certificates has expired. That's not a good thing, but my ISP decided I'm an idiot and gave me a condescending message about accepting expired certificate - unacceptable in my book. VPN helped. Too much dry code for my taste and not many remarks/explanations - that's not bad because for prose I'd recommend Martin's Fowler articles on Event processing, but…
Have you also considered C# for Event Sourcing? We've built many successful ES projects with C# and the awesome Marten library (https://martendb.io/). It's a real productivity multiplier for us.
Re: Event Sourcing in Go: From Zero to Production
#5Anyone who's built, run, evolved, and operated any reasonably sized event sourced system will know it's a total nightmare.
Immutable history sounds like a good idea, until you're writing code to support every event schema you ever published. And all the edge cases that inevitably creates.
CQRS sounds good, until you just want to read a value that you know has been written.
Event sourcing probably has some legitimate applications, but I'm convinced the hype around it is predominantly just excellent marketing of an inappropriate technology by folks and companies who host queueing technologies (like Kafka).
Re: Event Sourcing in Go: From Zero to Production
#6[flagged]
Re: Event Sourcing in Go: From Zero to Production
#7[flagged]
> or a third team starts depending on your event stream as an integration API.
> vents stop being an internal persistence detail and become a public contract.
You can't blame event sourcing for people not doing it correctly, though.
The events aren't a public contract and shouldn't be treated as such. Treating them that way will result in issues.
> Used as a generic CRUD replacement it’s a complexity bomb with a 12-18 month fuse.
This is true, but all you're really saying it "Use the right tool for the right job".
Re: Event Sourcing in Go: From Zero to Production
#8How does event sourcing handle aggregates that may be larger than memory?
Smaller aggregates.
You really don't want your streams/aggs to come close to being that large.
Re: Event Sourcing in Go: From Zero to Production
#9I'm going to have a word with my ISP. It seems that sites SSL certificates has expired. That's not a good thing, but my ISP decided I'm an idiot and gave me a condescending message about accepting expired certificate - unacceptable in my book. VPN helped. Too much dry code for my taste and not many remarks/explanations - that's not bad because for prose I'd recommend Martin's Fowler articles on Event processing, but…
> Go is one of the best languages to go for Event Sourcing toda
Can you explain this? Go has a very limited type system.
Re: Event Sourcing in Go: From Zero to Production
#10Anyone who's built, run, evolved, and operated any reasonably sized event sourced system will know it's a total nightmare. Immutable history sounds like a good idea, until you're writing code to support every event schema you ever published. And all the edge cases that inevitably creates. CQRS sounds good, until you just want to read a value that you know has been written. Event sourcing probably has some legitimate…
> CQRS sounds good, until you just want to read a value that you know has been written.
This is for you and the author apparently: Prating CQRS does not mean you're splitting up databases. CQRS is simply using different models for reading and writing. That's it. Nothing about different databases or projections or event sourcing.
This quote from the article is just flat out false:
> CQRS introduces eventual consistency between write and read models:
No it doesn't. Eventual consistency is a design decision made independent of using CQRS. Just because CQRS might make it easier to split, it doesn't in any way have an opinion on whether you should or not.
> by folks and companies who host queueing technologies (like Kafka).
Well that's good because Kafka isn't an event-sourcing technology and shouldn't be used as one.