7 things I learned from Martin Dilger on SE Radio #720 — "Understanding Event Sourcing":

1️⃣ Event sourcing ≠ event streaming. Kafka is the “highway” between systems. An event store is the memory of one system. Confusing the two is why ~90% of "we tried event sourcing and it failed" stories happen.

2️⃣ Two slice types is all you need. State-change slices (info goes in) and state-view slices (info comes out). Every system, no matter how big, decomposes into those two patterns.

3️⃣ Modeling beats coding. Start with event modeling, not implementation. The biggest project failures are communication failures, not technology failures.

4️⃣ Reuse is overrated. He hasn't used an abstract class in 5 years. Slices stay independent on purpose. Copy-paste is fine. DRY creates coupling, and coupling is the real cost driver.

5️⃣ Performance worry is usually based on a misunderstanding. You don't re-read all events on every request. You maintain persistent projections (often just a regular relational table). Same runtime behavior as CRUD — but you can rebuild any view at any point in time.

6️⃣ Events evolve gracefully. Prefer adding new events to changing existing ones. When you must change, version them and use an "up-caster." In practice, business processes are stable, so this rarely sprawls.

7️⃣ Slice cycle time is the metric to watch. How long does it take a team to ship one slice end-to-end (UI + logic + tests + production)? Starts at 2-3 days. Drops to half a day. That's the ROI signal.

Bonus: pairs incredibly well with AI coding agents. They never need to understand the whole codebase — just one slice. Tiny context window, big productivity bump.

The full episode is in Tech Talks Weekly #104 this week, alongside 170+ other talks and podcasts (Devoxx UK 2026, Voxxed Days Bucharest, AI Engineer Europe, NDC Security…):

Which of the 7 surprised you most?