Consider a microservices system that uses event sourcing. What is the main advantage of this pattern?
Think about how event sourcing handles data changes over time.
Event sourcing stores all changes as events, allowing the system to rebuild any past state by replaying these events.
In an event sourcing system, which component is responsible for storing all the events?
Think about where the system keeps the history of all changes.
The Event Store is the component that stores all events in the system, acting as the source of truth.
In a microservices system using event sourcing, how can read operations be scaled efficiently?
Consider how read models can be optimized separately from writes.
Event sourcing allows building specialized read models from events, which can be scaled independently to handle queries efficiently.
Which of the following is a typical downside of adopting event sourcing?
Think about the effort needed to get the current state from stored events.
Event sourcing requires replaying events to rebuild state, which adds complexity and can impact performance.
A microservice using event sourcing records 1000 events per minute. Each event is 1 KB in size. Estimate the storage needed after 1 year (assume 365 days).
Calculate total events per year and multiply by event size.
1000 events/min × 60 min/hr × 24 hr/day × 365 days = 525,600,000 events. Each event is 1 KB, so total storage ≈ 525,600,000 KB ≈ 525 GB.