Luis Galeas
CEO at Ambar
Actions
Luis' experience ranges from small startups up to work at Amazon Web Services. He's extremely knowledgeable about correctness in distributed applications, especially when it comes to event sourcing. He's particularly proud of the event sourcing workshops his company has been running for free, to help the community.
Links
The Hardest Problems in Event Sourcing: Projections and Sagas
Did event sourcing not turn out how you thought it would? Luis explored successes and failures with over 200 event sourcing practitioners, and he knows why many became disillusioned after shipping to production.
Event sourcing relies on projections, read models, sagas, and workflows, for which the event sourcing community has been saying, for years:
- "Just" read your SQL based event store
- "Just" use a queuing system like RabbitMQ or Kafka
- "Just" use NoSQL as your event store and stream from there
- "Just" use a specialized event store
But every “just” comes with complexities. And event sourcing practitioners take months, or years, to "just" get it right.
This hands on lab shows you why the problem is so complex, and gives you the techniques you need to solve the hardest problems in event sourcing without losing your sanity.
Event Sourcing is Incomplete
If you think about the events in an event sourcing application as nodes, in a graph of causes and consequences, can your event sourcing application build any arbitrary graph?
This might sound like an innocent academic question, but it is another way of asking:
"Can your event sourcing application model ANY domain?"
It turns out the answer is a big NO. Event sourcing cannot be used in many domains.
Come to this talk, to find out the type of applications you cannot implement with event sourcing, the implications of this limitation, and what you can do about it.
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top