In a microservices architecture, what is the main role of an event store?
Think about how event sourcing captures changes over time.
An event store records every change as an event, preserving the full history of state changes. This allows rebuilding state and auditing.
In an event-driven microservices system, which component consumes events from the event store to update the read database?
Consider the component responsible for transforming events into queryable data.
The event projector listens to events and updates read models to provide efficient query access.
You have a microservices system with an event store that receives thousands of events per second. Which approach best helps scale the event store for high write throughput?
Think about distributing load to avoid bottlenecks.
Partitioning by aggregate ID allows parallel writes to different partitions, improving throughput and scalability.
Using an event store to manage application state has benefits but also tradeoffs. Which of the following is a common tradeoff?
Consider what storing every change implies for storage.
Storing every event means the event store grows over time, requiring more storage compared to storing only current state.
Your microservices system generates about 1 million events per month. Each event averages 1 KB in size. Estimate the storage needed for 1 year of events, including a 20% overhead for indexing and metadata.
Calculate total event size, then add 20% overhead.
1 million events/month × 12 months = 12 million events/year. Each event is 1 KB, so 12 million KB = 12 GB. Adding 20% overhead: 12 GB × 1.2 = 14.4 GB.