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

41–50 of 126 posts

Re: Event Sourcing Is Hard (2019)

#41

Post by oskar_dudycz »

As this article pops out again, I'd like to the point that although it may have some valid points, those points are not about Event Sourcing. What's expressed in the article is the Event Streaming or Event-Driven approach. So when events are not the source of truth etc. All of the event stores that I know supports strong consistency on appends, optimistic concurrency. Many guarantee global ordering. Some help in idempotency. All of that helps to reduce those issues. In Event Sourcing, events are the state. So the flow looks like that:

1. You get the events from the stream (that represents all the facts that happened for the entity),

2. You apply it one by one in the order of appearance to build the current state,

3. You run the business logic and, as a result, create the event,

4. You append a new event.

You don't need to cache the write model state anywhere, as the state is in events. Event Sourcing has its issues and troubles, but the stuff described in the article apply to tools like Kafka, etc. They're not tools for Event Sourcing but Event Streaming. They're designed to move things from one place to another, not to be used as durable databases.

I've made a list of articles like that: https://github.com/oskardudycz/EventSourcing.NetCore#this-is...

I'll repeat it again: this is not Event Sourcing.

Re: Event Sourcing Is Hard (2019)

#44

Post by bruth »

geoduck14 wrote: post #39
bruth wrote: post #26

The title here is being overlooked, its not _terrible_, its _hard_. Also this quote from the article: > The bulk of these probably fall under "he obviously didn't understand X," or "you should never do Y!" in which case you would be absolutely right. The point of this is that I didn't understand the drawbacks or pain points until I'd gotten past the "toy" stage. Most of what they discussed was indeed not great, but t…

I've never heard of the term Event Sourcing. I AM familiar with Event Streaming. Some of what this article talks about surprised me - and I think it is because I don't fully understand the difference between Event Sourcing and Event Streaming. Is this article a fine summary?: https://developer.confluent.io/learn-kafka/event-sourcing/ev...

I have not watched that clip, but as I said above, Confluent isn't a good resource for defining this term since Kafka cannot be used to do ES. I would suggest an article like: https://domaincentric.net/blog/eventstoredb-vs-kafka

Also refer to the list of great resources @oskar_dudycz posted in another comment: https://github.com/oskardudycz/EventSourcing.NetCore#1319-th...

Re: Event Sourcing Is Hard (2019)

#45

Post by randolorian »

EdwardDiego wrote: post #34

Most common issue I've ever encountered with event sourcing is that devs submit events that when replayed, lead to invalid states. And if you're using an immutable log (Kafka/Pulsar/Liftbridge etc.) fixing those mistakes is hard. And given you're basically recording interim states of a state machine, how do you verify that event Z being submitted after event Y is a valid state transition? Validating a record against…

Seems like a fundamental misunderstanding to me. Commands get validated via your aggregate, not events. Events are not allowed to be rejected. Ever. Because they already happened.

Re: Event Sourcing Is Hard (2019)

#46

Post by kreetx »

oskar_dudycz wrote: post #41

As this article pops out again, I'd like to the point that although it may have some valid points, those points are not about Event Sourcing. What's expressed in the article is the Event Streaming or Event-Driven approach. So when events are not the source of truth etc. All of the event stores that I know supports strong consistency on appends, optimistic concurrency. Many guarantee global ordering. Some help in idem…

BTW, does there happen to be a discord channel for this topic? ;)

Re: Event Sourcing Is Hard (2019)

#47

Post by EdwardDiego »

randolorian wrote: post #45
EdwardDiego wrote: post #34

Most common issue I've ever encountered with event sourcing is that devs submit events that when replayed, lead to invalid states. And if you're using an immutable log (Kafka/Pulsar/Liftbridge etc.) fixing those mistakes is hard. And given you're basically recording interim states of a state machine, how do you verify that event Z being submitted after event Y is a valid state transition? Validating a record against…

Seems like a fundamental misunderstanding to me. Commands get validated via your aggregate, not events. Events are not allowed to be rejected. Ever. Because they already happened.

Thinking that event sourcing and CQRS are synonyms is a fundamental misunderstanding also.

Anyway, pedantry aside, my point remains thus - it's hard to prevent invalid state transitions being submitted to an event sourcing datastore, and when devs can submit events directly, then these invalid transitions will occur.

Re: Event Sourcing Is Hard (2019)

#48

Post by minimeme »

akiselev wrote: post #19

I've worked with several event sourcing systems and was even seduced into implementing one out of sheer hubris once. These problems are ever present in every ES project I've had the misfortune of coming into contact with. It doesn't even mention the worst part that comes afterwards, when you realize after all of that pain that it is only used by a single person in the company to generate a noncritical report comparin…

Event sourcing can be a very powerful pattern if used correctly. You don't need to combine ES with Eventual Consistency. ES can be implemented in a totally synchronous manner and it works very elegantly capturing nicely all the busines events you need. You get a very detailed audit for free and you don't loose importan business data. You can travel back in time, construct different views of data (projections) etc. Most of the complications arise when you bring in Eventual Consistency, but you absolutely don't have to.

Re: Event Sourcing Is Hard (2019)

#49

Post by DrBazza »

I've worked on a few event sourcing systems, and the only ones that have been truly successful are the ones where the system was written from scratch. Trying to retrofit systems never seemed to quite work as expected.

Also, the "from scratch" systems, seemed conceptually easier to not only understand, but extend, because you were forced to write code in an idiomatic and consistent way. Everything was an event (albeit, a "command" and an "event" confirming 'execution' of the "command").

Re: Event Sourcing Is Hard (2019)

#50

Post by randolorian »

EdwardDiego wrote: post #47
randolorian wrote: post #45

Earlier quoted context omitted.

Seems like a fundamental misunderstanding to me. Commands get validated via your aggregate, not events. Events are not allowed to be rejected. Ever. Because they already happened.

Thinking that event sourcing and CQRS are synonyms is a fundamental misunderstanding also. Anyway, pedantry aside, my point remains thus - it's hard to prevent invalid state transitions being submitted to an event sourcing datastore, and when devs can submit events directly, then these invalid transitions will occur.

> Thinking that event sourcing and CQRS are synonyms is a fundamental misunderstanding also.

Indeed. These are two separate patterns. They can have great synergy when used together but it's not a requirement.

> it's hard to prevent invalid state transitions being submitted to an event sourcing datastore

Apply DDD, use code review, and use stream level ACLs.

Post reply on HN