Slow Event Sourcing reprojections? Just make them faster!
summary
Practical tactics for speeding reprojections: make projectors asynchronous or project stream-by-stream to batch writes; use ORMs with batched flushes, in-memory or cached projections, or tombstoning/archival to skip closed streams. Add version metadata to events for safe rollbacks. Concrete wins: systems with ~55M events and ~100GB event stores cut rebuilds from five days to six hours, and a table-clone approach drops that to under two hours while keeping blue‑green deploys and immediate rollback.
AI-written summary · about
chapters (8)
- 0:00Introduction to reprojections
- 7:46Why reprojections matter
- 12:17Async projections and trade-offs
- 21:09Reducing data to reproject
- 27:09Cloning tables for speed
- 33:27Handling schema changes
- 38:30Versioning and autonomy
- 40:40Q&A and closing
related talks
43mEvent Sourcing dealing with an eventful past
51mThings I wish I knew before I started with event sourcing
48mEvent Sourcing - what could possibly go wrong?
01h 07mAn Architecture with CQRS and Event Sourcing
48mEvent Sourcing - what could possibly go wrong?
54mEvent Sourcing
49mCQRS and Event Sourcing explained
49mEvents... And what next?