Performance aspects of Axon-based CQRS-ES systems
summary
Axon Framework + Axon Server use an append-only event store split into disk-backed segments with an in‑memory index and bloom filters to keep append/read latency constant as size grows. Routing commands with consistent hashing reduces cache-invalidation conflicts; snapshotting reduces reconstruction spikes to a few events. Replays speed up by batching (1,000→~4,000 msg/s), parallelism (8 threads→~15,000 msg/s) and DB-optimized handlers (combined statements → 30,000 events/sec), turning a 10M-event replay from ~11 hours down to minutes.
AI-written summary · about
chapters (13)
- 0:00Introduction to Axon framework
- 1:26Performance challenges in CQRS-ES
- 8:15CQRS and event sourcing basics
- 14:18Event store performance issues
- 21:24Optimizing event store storage
- 22:06Aggregate loading and caching problems
- 26:51Snapshotting to reduce cache invalidation
- 30:08Replay performance bottlenecks
- 34:24Parallel processing and batching
- 37:01Optimizing event handlers
- 41:44Partial replay strategies
- 45:41Performance tuning summary
- 47:48Q&A session
related talks
46mAxon Framework : A CQRS Approach to Microservices
01h 12mDemystifying "event-based" software concepts and methodologies
47mCQRS and Event Sourcing on Steroids: Lessons Learned with Spring & Axon
39mPragmatic Microservices with DDD, CQRS and Event Sourcing Using Axon Framework
55mHands-on introduction o CQRS and Event Sourcing with Axon
51mBootiful CQRS and Event Sourcing with Axon Framework
01h 25mBuilding microservices with event sourcing and CQRS
36mBeyond DDD 101 — a practice report on building multi–bounded‑context CQRS/ES applications