Give Your Application Memories
summary
Claims that storing every change (events) instead of only current state enables new features later: demo builds a Java shopping cart aggregate using Axon Framework and Axon Server event store, publishes commands/events, and runs two microservices plus an upsell projection that grants a 10% discount to users who added but didn’t buy. Demo persists ~50k visible events (author notes a 500M run), reconstructs state by replay or snapshot, shows working queries and projections, and discusses snapshots, upcasters, sagas and linear performance vs Postgres.
AI-written summary · about
chapters (8)
- 0:00Introduction and welcome
- 1:05What are memories in software?
- 8:09Event sourcing explained
- 11:41Live code demonstration
- 24:38Late requirement use case
- 29:56Handling event store growth
- 35:20Production considerations
- 38:12Summary and closing
related talks
52mHidden gems and traps that you probably didn't think of using Event Sourcing
43mEvent Sourcing dealing with an eventful past
50mThe harsh reality of Event Sourcing - mitigated with Spring and Axon on Tanzu Application Platform
55mHands-on introduction o CQRS and Event Sourcing with Axon
01h 12mDemystifying "event-based" software concepts and methodologies
46mState or events? Which shall I keep?
54mHow Events Are Reshaping Modern Systems
56mEvents on the outside, on the inside and at the core