Introducing Event Sourcing into the Monolith: A Travelogue
summary
A 13-year-old Ruby on Rails monolith keeps handling domain registrations and transfers but the team introduces event sourcing for a core product path: they start by recording events alongside the existing processor, wrap steps into idempotent commands, and project event streams back into customer-facing state. They build an evented domain transfer processor, add an admin UI showing event lists and actor metadata, learn to use unique IDs and avoid archiving raw events, and hit seven consecutive days without any fail sales order as proof it works.
AI-written summary · about
chapters (13)
- 0:00Introduction
- 1:13Speaker and journey
- 2:58Domain management complexity
- 6:10Sales order system
- 9:21Domain workflow
- 12:08Domain transfer challenges
- 15:41Legacy processor problems
- 19:52Event sourcing benefits
- 25:48Event sourcing in sales
- 31:47Code structure changes
- 34:14Lessons learned
- 39:33Event sourcing without over-engineering
- 40:13Impact and achievements
related talks
39mEvent Sourcing with Elixir
43mEvent Sourcing dealing with an eventful past
49mEvents... And what next?
52mEvent Sourced Transformation in Financial Systems
49mCQRS and Event Sourcing explained
48mEvent Sourcing - what could possibly go wrong?
52mUse the Source, Luke: High-fidelity history with event-sourced data
56mEvents on the outside, on the inside and at the core