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

Event Sourcing Is Hard (2019)

chriskiehl.com

Post reply on HN
Print view View original

1–10 of 126 posts

Re: Event Sourcing Is Hard (2019)

#6

Post by brianmcc »

wongarsu wrote: post #3

Previous discussion (2019): https://news.ycombinator.com/item?id=19072850 Has anything changed since then? Is there new tooling that resolves some of the pain points, or new techniques that change the picture?

A whole new bunch of people for whom the article hits home maybe. In any case - it's a new one to me, and thanks for the link to earlier discussion, v interesting!

Re: Event Sourcing Is Hard (2019)

#7

Post by bob1029 »

> The idea of a keeping a central log against which multiple services can subscribe and publish is insane.

Is event sourcing about storing 1 authoritative, immutable, serialized narrative of events, or is it about tying together a pile of microservices?

I think the part where it goes wrong is where we try to subscribe to these events (i.e. push). This adds delivery semantics to the mix and forces a lot more constraints at vendor selection time. Being notified that something occurred is not part of event sourcing in my mind (though it is clearly one logical extenstion).

Re: Event Sourcing Is Hard (2019)

#8

Post by misja111 »

alecco wrote: post #4

Event Sourcing sucks. I blame OOP abstractions taken to an extreme. https://vvvvalvalval.github.io/posts/2018-11-12-datomic-even...

Strange that you blame this on OOP. I see event sourcing being used particularly often in FP environments. Because of course the model of streaming immutable data fits very well into the FP paradigm.
Post reply on HN