Event Sourcing You are doing it wrong by David Schmitz

"Every microservice get's its own database and then use Kafka" is a typical and naive advise, when reading about eventsourcing. If you approach this architectural style this way, you will probably have a really awful time ahead.

Eventsourcing and CQRS are two very useful and popular patterns when dealing with data and microservices. We often find in our customer's projects, that both have a severe impact on your future options and the maintainability of your architecture. Presentations and articles on both topics are often superficial and do not tackle real world problems like security and compliance requirements.

This combination of half-knowledge and technical confusion leads to many projects that either refactor back to a 'non-eventsourced' architecture or reduce eventsourcing to a message queue.

In this talk, I will summarize our experience while applying eventsourcing and CQRS accros multiple large financial and insurance companies over the last 5 years. We will cover the Good, the Not so Good, and the 'oh my god...all abandon ships!' when doing eventsourcing in the real world...and see how we solved these issues.

David Schmitz
From Senacor Technologies
Principal architect at Senacor Technologies with a history of + 16 years of working in various projects using a bunch of different stacks and environments.

Current focus is on migrating architectures and organizations to cloud and serverless platforms.

[DodaGarcia]

9:25 "So, end of talk. Maybe not" 😂😂😂 I love how deadpan he is

[tiagodagostini]

Sorry but solving a 100 event stream in 66 ms is NOT fast. it is ABSURDLY slow when you figure the total expected data troughput of a modern computer. it would need to be 66 Microsseconds to be reasonably fast.

[tyrotoxin]

First part is about Partial Ordering of events which guarantees Causal Consistency model in distributed systems. Don't think that it comes for free though.

The ability to specify an offset on emitting events to Kafka (aka "Lamport Clocks") creates a "lock" per partition what impacts performance as you have many concurrent producers. Besides, you need to emit events for the same Aggregate into the same partition - that reduces the Availability.

Those are the right things to do though if you want to trade the Performance and Availability in favor of Consistency. And most likely you want to do so instead of putting that complexity into the application layer. Just be aware that the approach has its price.

[MykolaKlymyuk]

How do you solve 'Set validation' problem?

[RikiPoon]

6:26 take away the eventstore and the whole thing still works. To me it seems to be depicting event-driven architecture rather than event sourcing, as we make no use of the eventstore at this picture

[MerrionGT]

One stream per aggregate is, of course, the way to go! Also - both logically and physically distinct.

[nimrodsadeh]

Aren't event handlers that read from persistent storage CPU intensive since they deserialize every event?

Can you build an "event sourced" system iteratively?
It's very seldom you actually know your domain well enough to specify it in advance, and even if you do, it will most likely change.
That would be an interesting topic to discuss and compare between different architectures.

[LonliLokli]

I really like your talk! The only thing I miss is a discussion on after-party.

[DavidCumps]

How does GDPR deal with the requirement of storing data for fraud detection as a bank? I cannot image a customer can have his bank history forgotten to be hard deleted? Doesn't the government require an audit trail in case you are charged in court?

[dmsanz_youtube]

I liked it, but saying that read models is overrated could be very confusing especially considering that 80%-90% of the interactions with our web applications are "read" operations and also considering that one of the most powerful advantages of event sourcing with CQRS is the ability to replay the events in a stream in order to rebuild a read model (e.g: new geodistributed infinite cache) or in order to create a complete new one (e.g: reports).
In my opinion read models are actually underrated and having a good event versioning and replaying strategy is crucial.

[nimrodsadeh]

Also, in the part about query aggregates you said to just put all the streams that correspond to your query in a bigger stream (e.g., users > 18 years old). This is a good example because it changes all the time; your users grow up and become 18. Wouldn't the logic to handle moving streams around like this become a bit cumbersome?

[codematrix]

Here's my take. The current industry state of event sourcing is still not well defined and there seems to be too many flavors on what is right and what is wrong. Like all greenfield approaches to solve a problem, I tend not go into it so quickly until a consistent well defined approach becomes the leading defacto. My suggestion, don't build your own homegrown ES because it will be a hodgepodge colossal mess and a maintenance nightmare. I plan to wait until AWS or Azure, come with a viable solution and the let them worry about the implantation and maintenance while I worry about the meat of my microservices.

[jinhanchoi]

one stream means a topic for one user?

[devproco]

Can you explain what `emitEvents` does?
- does it _apply_ events to an aggregate?
- does it save events generated by an aggregate (eg `executeBusinessLogic()`)?
Is the `Account.lastEventNumber !== Stream.lastEventNumber` supposed to occur in the storage implementation? For example, inside of `Stream.append()`?

[rum]

whatever he says "super easy" i find it difficult to follow

[bluejanis]

What about commands? Your talk never mentioned them. CQRS =

[boot-strapper]

Luckily we dont have to go to ops to ask for anything now because AWS offers managed kafka.

[JeremyAndersonBoise]

One of the most hilarious presenters in tech. Love him.

[placidchat]

If eventstore documentation is awful but the community is great, how would you choose this library vs every other one out there?