00:05Hello, everyone. I'm Oliver, and a warm welcome to Day 25 of the 50 Days Software Architecture
00:11class. In Day 24, we explored the CQRS pattern for separating reads and writes. Today, we're
00:16diving into event sourcing as a way to store application state as a sequence of events,
00:20a powerful technique that captures every change immutably, enabling audit trails,
00:24time travel, and seamless scalability. Let's get started.
00:27Let's outline Day 25 in greater depth. Event sourcing stores the entire application state
00:33as an immutable sequence of domain events rather than updating records directly, allowing us to
00:39rebuild the current state by replaying events from the beginning. We'll cover the core mechanics,
00:46benefits like complete audit trails and time travel capabilities, and how it integrates
00:51beautifully with Day 24's CQRS for optimized read-write models and Day 23's hexagonal
00:59architecture for clean boundaries. This also connects to domain events from Day 22's DDD,
01:05where every business change becomes a permanent, replayable fact.
01:09A paradigm shift. These concepts will show how to build systems that never lose history
01:14and can answer what-if questions with ease.
01:17Here's a quick overview of what we'll cover today. Event sourcing treats the sequence
01:22of events as the single source of truth instead of mutable state. Current state is reconstructed
01:27by replaying all events from the beginning or from a snapshot. We'll explore advantages like
01:33perfect auditability, natural scalability through event streams, and flexibility to derive new read
01:38models. This synergizes with Day 24's CQRS by powering the command side with events and Day 17's
01:47reliability through replayable history for recovery. Why choose event sourcing? It provides a complete,
01:53immutable audit trail of every state change, essential for compliance and debugging.
01:59Time travel queries let you reconstruct any past state for analysis or what-if scenarios.
02:05Scalability improves because event streams can be partitioned and processed independently.
02:10It enhances Day 17's reliability by allowing full state rebuild after failures or data corruption.
02:18Covering the basics of event sourcing. Events are immutable facts representing what happened in the
02:24domain, such as order placed or payment processed. The event store is an append-only log where events are
02:32written sequentially. Projections rebuild read models by processing events. Snapshotting periodically saves
02:39current state to speed up replay for long histories. Event sourcing workflow. A command arrives,
02:45business logic validates it against current state, and produces new domain events. Events are appended
02:51immutably to the store. On read, the current state is rebuilt by replaying events from the log.
02:58Projections then update query models asynchronously for fast reads.
03:03Event sourcing with CQRS. The command side processes business logic and appends events to the store.
03:09The query side subscribes to events and builds optimized projections. Eventual consistency keeps
03:16the read model in sync over time. This delivers Day 24's benefits by giving each side its ideal model
03:22while preserving full history. Domain events in event sourcing. Make events rich with business context,
03:29not just technical changes. Keep them immutable to preserve history forever.
03:34Version events to evolve schemas without breaking replays. Publish them for integration with Day 9
03:41PubSub systems. Event sourcing benefits. Full auditability with every change recorded forever.
03:47Temporal queries reconstruct state at any point in time. Scalability improves as event streams can be
03:54partitioned and processed independently. Resilience shines by rebuilding state after any failure,
04:00tying to Day 17. Event sourcing challenges. Eventual consistency can cause brief read lags.
04:07Storage grows with every event, requiring pruning strategies. Replay performance for long histories
04:13needs snapshots. Schema evolution demands careful versioning to avoid breaking existing events.
04:20Implementing event sourcing. Use a dedicated append-only event store for persistence.
04:26Rehydrate aggregates by replaying events from Day 22. Build projections with event handlers that
04:32update read models. Tools like Event Store DB or Axon Framework provide full support for streams,
04:38snapshots, and subscriptions. Event sourcing in microservices. Each service owns its event stream for
04:45autonomy. Integrate via published events from Day 9. Combine with Day 24 CQRS by letting commands
04:52produce events that feed query projections. Deploy in Day 20 cloud-native containers for independent
04:58scaling. Event sourcing best practices. Treat events as immutable facts with rich business meaning.
05:06Use snapshots periodically to optimize replay performance. Make event handlers idempotent for safe
05:13replays. Version events carefully to maintain backward compatibility as the domain evolves.
05:19Advanced event sourcing challenges. Rebuilding query models after schema changes requires careful
05:25migration. Event ordering can be tricky in distributed systems. Use sequence numbers. Long-term storage
05:33costs grow with history. Plan archiving. Debugging often involves simulating replays from specific points.
05:39Event sourcing with CQRS. Commands produce events that are stored immutably. Queries rebuild read
05:47models from projections of those events. This creates perfect separation between write-optimized command
05:53models and read-optimized query models. It forms the foundation for Day 25's full event sourcing
05:59implementations. Event sourcing in cloud-native trigger serverless functions from Day 10 on new events.
06:06Use Kubernetes stateful sets for persistent event stores. Define ports in Day 23 hexagonal architecture
06:13for event publishing. Scale by partitioning event streams per Day 16 patterns. Implementing event sourcing.
06:20Use a dedicated append-only event store for persistence. Rehydrate aggregates by replaying events from Day 22.
06:28Build projections with event handlers that update read models. Tools like Event Store DB or Axon Framework
06:35provide full support for streams, snapshots, and subscriptions. Advanced event sourcing patterns.
06:41Snapshotting periodically saves current state to speed up replays. Version events for safe schema
06:47evolution. Use sagas for coordinating long-running business processes. Build multiple projections for
06:54different read models from the same events. Common event sourcing pitfalls. Creating too many tiny events
07:01causes event explosion and storage bloat. Poor versioning leads to breaking changes during replays.
07:07Over-replaying long histories without snapshots hurts performance. Ignoring eventual consistency can
07:13create confusing user experiences. Recapping Day 25, we explored event sourcing as storing application
07:21state as an immutable sequence of events. Covered state reconstruction, projections,
07:26integration with CQRS and hexagonal, and pitfalls. The key takeaway? Event sourcing turns history into the
07:34single source of truth for auditability, scalability, and resilience.
07:39Day 25 of the 50 Days Software Architecture class on YouTube. Moderated by Anastasia and Irene,
07:47today's focus is on event sourcing as a way to store application state as a sequence of events,
07:53providing a detailed exploration of how this pattern captures every state change as an immutable
07:59event. Enabling powerful features like full audit trails, time travel queries, and seamless
08:06integration with CQRS for highly scalable and resilient systems. The session is designed to run 15-20
08:13minutes, approximately 60 words per minute, total word count 1650 with natural delivery, and expanded
08:21explanations for in-depth analysis of event sourcing mechanics. Replay strategies and consistency models,
08:28and real-world application patterns to build systems that are both historically accurate and future-proof.
08:35We've organized it into 20 slides, each with four bullet points, and extended conversational scripts from both
08:41moderators to provide more comprehensive insights and balanced dialogue. To ensure more equal time distribution,
08:50Anastasia and Irene alternate leading sections more evenly. Anastasia handles slides 1-5 and 11-15,
08:59intro, basics, and some implementation. Irene leads slides 6-10 and 16-18, advanced patterns and integration.
09:08And slides 19-20 are shared for recap and closing. This builds on Day 24's CQRS pattern,
09:15incorporating Day 23's hexagonal architecture for event-driven ports, and aligns with Day 2's solid for
09:22designing immutable event-based models. Pauses, transitions, and visuals, including event stream diagrams,
09:31will enhance the flow and aid in understanding state reconstruction. Day 26 covers API Gateway
09:37patterns for managing microservices traffic and security. For homework, model a simple event stream
09:44for a small feature, identifying key domain events. Questions from today? Drop them in the comments,
09:51Irene and I will respond. Thanks so much for joining us. If this helped, give it a like, share with
09:57your network,
09:58and subscribe for the full series.
Comments