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

11–20 of 55 posts

Re: Event Sourcing in Go: From Zero to Production

#11

Post by zknill »

anthonylevine wrote: post #10
zknill wrote: post #5

Anyone 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 consistenc…

Please explain how you intend to use different models for reading and writing without there being some temporal separation between the two?

Most all CQRS designs have some read view or projection built off consuming the write side.

If this is not the case, and you're just writing your "read models" in the write path; where is the 'S' from CQRS (s for segregation). You wouldn't have a CQRS system here. You'd just be writing read optimised data.

Re: Event Sourcing in Go: From Zero to Production

#12

Post by mrkeen »

anthonylevine wrote: post #10
zknill wrote: post #5

Anyone 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 consistenc…

> Just because CQRS might make it easier to split

Or segregate even.

Re: Event Sourcing in Go: From Zero to Production

#13

Post by mrsmrtss »

anthonylevine wrote: post #10
zknill wrote: post #5

Anyone 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 consistenc…

Yes, I don't know where the misconception that CQRS or Event Sourcing automatically means eventual consistency comes from. We have built, run, evolved, and operated quite a few reasonably sized event sourced systems successfully, and these systems are running to this day without any major incidents. We added eventually consistent projections where performance justified it, fully aware of the implications, but kept most of the system synchronous.

Re: Event Sourcing in Go: From Zero to Production

#14

Post by mrkeen »

fleahunter wrote: post #6

[flagged]

> Event sourcing shines when the business actually cares about history (finance, compliance, complex workflows)

Flip it on its head.

Would those domains be better off with simple crud? Did the accountants make a wrong turn when they switched from simple-balances to single-entry ledgers?

Re: Event Sourcing in Go: From Zero to Production

#15

Post by zknill »

mexicocitinluez wrote: post #7
fleahunter wrote: post #6

[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-1…

> You can't blame event sourcing for people not doing it correctly, though.

Perhaps not, but you can criticise articles like this that suggest that CQRS will solve many problems for you, without touching on _any_ of its difficulties or downsides, or the mistakes that many people end up making when implementing these systems.

Re: Event Sourcing in Go: From Zero to Production

#16

Post by azkalam »

zknill wrote: post #11
anthonylevine wrote: post #10

Earlier quoted context omitted.

> 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 consistenc…

Please explain how you intend to use different models for reading and writing without there being some temporal separation between the two? Most all CQRS designs have some read view or projection built off consuming the write side. If this is not the case, and you're just writing your "read models" in the write path; where is the 'S' from CQRS (s for segregation). You wouldn't have a CQRS system here. You'd just be w…

- Write side is a Postgres INSERT

- Read side is a SELECT on a Postgres view

Re: Event Sourcing in Go: From Zero to Production

#17

Post by [deleted] »

zknill wrote: post #11
anthonylevine wrote: post #10

Earlier quoted context omitted.

> 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 consistenc…

Please explain how you intend to use different models for reading and writing without there being some temporal separation between the two? Most all CQRS designs have some read view or projection built off consuming the write side. If this is not the case, and you're just writing your "read models" in the write path; where is the 'S' from CQRS (s for segregation). You wouldn't have a CQRS system here. You'd just be w…

[deleted]

Re: Event Sourcing in Go: From Zero to Production

#18

Post by zknill »

azkalam wrote: post #16
zknill wrote: post #11

Earlier quoted context omitted.

Please explain how you intend to use different models for reading and writing without there being some temporal separation between the two? Most all CQRS designs have some read view or projection built off consuming the write side. If this is not the case, and you're just writing your "read models" in the write path; where is the 'S' from CQRS (s for segregation). You wouldn't have a CQRS system here. You'd just be w…

- Write side is a Postgres INSERT - Read side is a SELECT on a Postgres view

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

Re: Event Sourcing in Go: From Zero to Production

#20

Post by anthonylevine »

zknill wrote: post #15
mexicocitinluez wrote: post #7

Earlier quoted context omitted.

> 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-1…

> You can't blame event sourcing for people not doing it correctly, though. Perhaps not, but you can criticise articles like this that suggest that CQRS will solve many problems for you, without touching on _any_ of its difficulties or downsides, or the mistakes that many people end up making when implementing these systems.

CQRS is simply splitting your read and write models. That's it.

It's not complicated or complex.

Post reply on HN