Event Sourcing & CQRS with FastAPI and Celery.
summary
Builds an append only event store with events containing id, aggregate id, type, timestamp, schema version, revision and data, and wires writes through FastAPI and Pydantic into command handlers that load aggregates, produce events, and persist them to the store and an event bus. Projections run as Celery tasks with retry/backoff (using async-to-sync shims) to update read models. Solves 10k-event replay slowness with snapshots for 10k-event streams, surfaces eventual consistency with optimistic UI or outbox status, and turns bugs into pytest time‑travel debugging.
AI-written summary · about
chapters (17)
- 0:00Introduction to talk
- 1:16Classic database limitations
- 2:01Event sourcing fundamentals
- 4:05CQRS pattern explained
- 7:24Write and read flows
- 8:51FastAPI implementation
- 10:25Command handler deep dive
- 11:31Aggregate business logic
- 12:36Celery for event processing
- 14:52Handling event loss risks
- 16:02Projection updates
- 17:52Eventual consistency challenges
- 21:12Outbox pattern for UI
- 22:41Performance with snapshots
- 24:14Debugging with event sourcing
- 26:44When to avoid event sourcing
- 28:39Summary and key takeaways
related talks
56mDeveloping Event-driven Microservices w/Event Sourcing and CQRS
39mEvent Sourcing made Simple
40mEvent Sourcing: the good, the bad and the complicated
52mEvent Sourcing and CQRS
25mCQRS and Event Sourcing: May the Event Be with You
49mCQRS and Event Sourcing explained
46mMicroservices Data Patterns: CQRS & Event Sourcing
36mThe Good, The Bad and The Ugly - An Event Sourcing Retrospective
