Event Sourcing as a creative tool for developers

2 points

a year ago

Event sourcing is an architecture where you capture every change in your system as an immutable event, rather than just storing the latest state. Instead of only knowing what your data looks like now, you keep a full history of how it got there. In a simple crud app that would mean that every deleted, updated, and created entry is stored in your event source, that way when you replay your events you can recreate the state that the application was in at any given time.

Most developers see event sourcing as a kind of technical safety net: - Recovering from failures - Rebuilding corrupted read models - Auditability

Surviving schema changes without too much pain

And fair enough, replaying your event stream often feels like a stressful situation. Something broke, you need to fix it, and you’re crossing your fingers hoping everything rebuilds cleanly.

What if replaying your event history wasn’t just for emergencies? What if it was a normal, everyday part of building your system?

Instead of treating replay as a recovery mechanism, you treat it as a development tool — something you use to evolve your data models, improve your logic, and shape new views of your data over time. More excitingly, it means you can derive entirely new schemas from your event history whenever your needs change.

Your database stops being the single source of truth and instead becomes what it was always meant to be: a fast, convenient cache for your data, not the place where all your logic and assumptions are locked in.

With a full event history, you’re free to experiment with new read models, adapt your data structures without fear, and shape your data exactly to fit new purposes — like enriching fields, backfilling values, or building dedicated models for AI consumption. Replay becomes not about fixing what broke, but about continuously improving what you’ve built.

And this has big implications — especially when it comes to AI and MCP Servers.

Most application databases aren’t built for natural language querying or AI-powered insights. Their schemas are designed for transactions, not for understanding. Data is spread across normalized tables, with relationships and assumptions baked deeply into the structure.

But when you treat your event history as the source of truth, you can replay your events into purpose-built read models, specifically structured for AI consumption.

Need flat, denormalized tables for efficient semantic search? Done. Want to create a user-centric view with pre-joined context for better prompts? Easy. You’re no longer limited by your application’s schema — you shape your data to fit exactly how your AI needs to consume it.

And here’s where it gets really interesting: AI itself can help you explore your data history and discover what’s valuable.

Instead of guessing which fields to include, you can use AI to interrogate your raw events, spot gaps, surface patterns, and guide you in designing smarter read models. It’s a feedback loop: your AI doesn’t just query your data — it helps you shape it.

So instead of forcing your AI to wrestle with your transactional tables, you give it clean, dedicated models optimized for discovery, reasoning, and insight.

And the best part? You can keep iterating. As your AI use cases evolve, you simply adjust your flows and replay your events to reshape your models — no migrations, no backfills, no re-engineering.