Let's build the worst Event Sourcing system!
summary
Project France deliberately replaces an event store with Kafka-style queues and defaults, causing stale reads, lost idempotency, and broken ordering under load; a key limit is 200,000 Kafka partitions so per-stream partitioning doesn't scale, optimistic concurrency only works on real event stores, snapshots and monthly stream rotation try to mask growing IO costs, and the team builds a custom event store after a year of failures—event streaming ≠ event store and they explicitly skip the outbox pattern.
AI-written summary · about
chapters (19)
- 0:00Intro
- 0:34Team
- 2:02Competitors
- 2:44First idea
- 5:21Best case scenario
- 6:42Worst case scenario
- 8:32IDM potency
- 10:34Event ordering
- 16:58What is Event Sourcing
- 24:20Optimistic concurrency
- 25:46Atomicity optimistic concurrency
- 26:33Kafka
- 27:48Strategy
- 30:36Why is it so hard
- 32:58The case and architecture
- 35:51Network partitioning
- 44:50Stream design
- 47:55Stream length
- 53:09Final Touch
related talks
48mEvent Sourcing - what could possibly go wrong?
49mDemystifying ‘Event’ Related Software Concepts and Methodologies
51mThings I wish I knew before I started with event sourcing
43mEvent Sourcing dealing with an eventful past
54mEvent Sourcing
19mHow to Fail Your Event-Driven System
52mEvent-driven vs event sourcing: what's really the difference?
01h 07mAn Architecture with CQRS and Event Sourcing