In a microservices architecture, event replay is often used. What is its main goal?
Think about why a service might need to process old events again.
Event replay allows a service to reconstruct its state by reprocessing past events, especially after failures or schema changes.
To support event replay, which component must be part of the system design?
Consider where events must be kept to allow replay.
An event store that saves all events in order is necessary to replay events and rebuild state.
When the event log becomes huge, replaying all events can be slow. Which approach best improves replay efficiency?
Think about saving partial progress to avoid replaying everything from the start.
Snapshots store intermediate states so replay can start from a recent snapshot, reducing the number of events to process.
Choosing to keep all events for replay has benefits and drawbacks. What is a major tradeoff?
Consider what storing all events costs and what benefits it brings.
Keeping all events requires more storage and system complexity but enables full recovery and auditing of state changes.
A microservice generates 1000 events per second. Each event is 1 KB in size. How much storage is needed to keep events for 30 days to support event replay?
Calculate total events per day, multiply by event size, then by 30 days.
1000 events/sec * 86400 sec/day = 86,400,000 events/day. Each event 1 KB = 86.4 GB/day. For 30 days: 86.4 GB * 30 = 2.592 TB ≈ 2.6 TB.