Advanced
Event-Driven Architecture
Event sourcingCQRSArchitecture
Event Sourcing & CQRS — Vocabulary
5 exercises — Learn event sourcing and CQRS vocabulary: event store, projections, command handlers, and snapshots.
0 / 25 completed
1 / 25
In event sourcing, the source of truth for application state is:
Event sourcing stores every state change as an immutable event. The current state of any aggregate is derived by replaying all its events — the log IS the database, not a log of changes to a database.
2 / 25
A projection in event sourcing is:
Projections consume the event stream and build query-optimised read models (e.g., a denormalised view, a search index, an analytics aggregate). Because events are immutable, projections can always be rebuilt from scratch.
3 / 25
CQRS stands for:
CQRS separates the write model (command side: validates and processes commands, emits events) from the read model (query side: optimised projections for queries). This allows each side to be scaled and optimised independently.
4 / 25
Why do event-sourced systems use snapshots?
As aggregates accumulate events over time, replaying all events to load aggregate state becomes expensive. Snapshots store the aggregate's state at a specific event sequence number — the system replays only events after the snapshot.
5 / 25
Which sentence correctly describes the command handler in a CQRS architecture?
The command handler receives a command, loads the aggregate from the event store (replaying events or loading a snapshot), validates the command against business rules, and if valid, produces new domain events that are appended to the store.
6 / 25
Sarah: 'Hey team, I'm struggling with the PR. The event stream for the `UserOrder` service is *massive*, and querying it directly to get a list of recent orders is taking ages! We're using an Event Sourcing pattern here, so what's the most efficient way to build this view? (Excerpt from Slack conversation)The correct answer is option 1. While indexing or batch processing might offer *some* performance gains, they don't fundamentally address the problem of a large, constantly growing event stream. A projection – a read model built from events – is precisely what Event Sourcing is designed for: to create optimized views tailored for specific query needs. This avoids overloading the core event store and maintains consistency by reacting to new events.
7 / 25
John: 'I've reviewed the PR for the `ShoppingCart` service. The team is using Event Sourcing and a projection strategy to build the real-time inventory dashboard. I noticed that the PR description mentions creating a new event handler specifically for 'InventoryUpdated' events. Is this the correct approach, or are there alternative ways to ensure consistency between the source of truth (the event stream) and the dashboard view? The PR description currently says: 'This PR implements an event handler to react to `InventoryUpdated` events in the Event Store, ensuring that the inventory dashboard reflects these changes in near real-time.'
The key misunderstanding here is that while reactive handling (an event handler) *is* a valid part of an Event Sourced system, it's not the *most* efficient or common approach for building projections. In this scenario, the team is correctly utilizing an event handler to react to `InventoryUpdated` events. However, the correct answer highlights that creating a dedicated handler guarantees consistency by directly consuming the event stream and ensuring the dashboard reflects those changes in near real-time. Options A and D suggest incorrect strategies – simply reacting isn't enough for a projection, and direct subscription without handlers would likely lead to data lag or complex logic within the dashboard itself.
8 / 25
Reviewer: 'The team's using Event Sourcing and projections for the `OrderProcessing` service. I noticed they're creating a separate *read model* derived from the event stream to power the reporting dashboard. They've described it as 'synchronizing the view with the source of truth'. Does this align with best practices in an Event-Driven Architecture, or is there a more refined approach?', (Excerpt from Code Review Comment)The core concept here is understanding how projections relate to Event Sourcing. While 'synchronizing the view' isn't incorrect in its simplest form, it doesn't fully address potential issues like eventual consistency and query optimization. Projections should be carefully designed—defining specific data transformations and update strategies—to ensure accuracy and performance. Option 0 correctly identifies this nuance; a robust projection strategy involves more than just mirroring the event stream.
9 / 25
PR Description:
"This PR introduces a new event handler named `ProcessPaymentEvent` that consumes events from the `PaymentService`'s event stream. This handler updates the `OrderStatus` in our system to 'Paid' whenever a `PaymentSuccessful` event is received. We are using CQRS, so this ensures the order details remain consistent across all systems."This question tests understanding of how event handlers fit into a CQRS architecture. The correct answer highlights that decoupling updates via an event handler is a core benefit – it allows for independent scaling and responsiveness without directly impacting the source of truth (the event stream). Options A is incorrect because direct database updates bypass the benefits of CQRS, option C misinterprets the purpose of a handler in this context, and option D incorrectly states that immediate reaction is always best practice.
10 / 25
David: 'Hey team, I'm working on optimizing the user profile service. We're using Event Sourcing and projections to create a 'User Activity Timeline' view for each user. The event stream is growing rapidly, and the projection logic is becoming quite complex. I've been considering using a snapshot to reduce the load on the event store during queries. Does this sound like a reasonable strategy, or am I overlooking something crucial about maintaining consistency in an Event-Driven system? Specifically, I'm worried about divergence between the raw events and the timeline view.'This question assesses understanding of the purpose of snapshots in Event Sourcing. Snapshots provide a point-in-time representation of the aggregate state, allowing projections to quickly initialize without processing all historical events. The key misconception is that snapshots always increase overhead – they actually *reduce* it by providing a starting point and minimizing the need for full event replay during queries. The correct answer highlights their role in reducing query load; options B & C misrepresent snapshot usage and potential inconsistencies, while option A incorrectly states a universal performance penalty.
11 / 25
Sarah: 'Hey team, I'm struggling with the PR. The event stream for the `UserOrder` service is *massive*, and querying it directly to get a list of recent orders is taking ages! We're using an Event Sourcing pattern here, so what's the most efficient way to build this view? (Excerpt from Slack conversation)The correct answer is option 1. While indexing or batch processing might offer *some* performance gains, they don't fundamentally address the problem of a large, constantly growing event stream. A projection – a read model built from events – is precisely what Event Sourcing is designed for: to create optimized views tailored for specific query needs. This avoids overloading the core event store and maintains consistency by reacting to new events.
12 / 25
John: 'I've reviewed the PR for the `ShoppingCart` service. The team is using Event Sourcing and a projection strategy to build the real-time inventory dashboard. I noticed that the PR description mentions creating a new event handler specifically for 'InventoryUpdated' events. Is this the correct approach, or are there alternative ways to ensure consistency between the source of truth (the event stream) and the dashboard view? The PR description currently says: 'This PR implements an event handler to react to `InventoryUpdated` events in the Event Store, ensuring that the inventory dashboard reflects these changes in near real-time.'
The key misunderstanding here is that while reactive handling (an event handler) *is* a valid part of an Event Sourced system, it's not the *most* efficient or common approach for building projections. In this scenario, the team is correctly utilizing an event handler to react to `InventoryUpdated` events. However, the correct answer highlights that creating a dedicated handler guarantees consistency by directly consuming the event stream and ensuring the dashboard reflects those changes in near real-time. Options A and D suggest incorrect strategies – simply reacting isn't enough for a projection, and direct subscription without handlers would likely lead to data lag or complex logic within the dashboard itself.
13 / 25
Reviewer: 'The team's using Event Sourcing and projections for the `OrderProcessing` service. I noticed they're creating a separate *read model* derived from the event stream to power the reporting dashboard. They've described it as 'synchronizing the view with the source of truth'. Does this align with best practices in an Event-Driven Architecture, or is there a more refined approach?', (Excerpt from Code Review Comment)The core concept here is understanding how projections relate to Event Sourcing. While 'synchronizing the view' isn't incorrect in its simplest form, it doesn't fully address potential issues like eventual consistency and query optimization. Projections should be carefully designed—defining specific data transformations and update strategies—to ensure accuracy and performance. Option 0 correctly identifies this nuance; a robust projection strategy involves more than just mirroring the event stream.
14 / 25
PR Description:
"This PR introduces a new event handler named `ProcessPaymentEvent` that consumes events from the `PaymentService`'s event stream. This handler updates the `OrderStatus` in our system to 'Paid' whenever a `PaymentSuccessful` event is received. We are using CQRS, so this ensures the order details remain consistent across all systems."This question tests understanding of how event handlers fit into a CQRS architecture. The correct answer highlights that decoupling updates via an event handler is a core benefit – it allows for independent scaling and responsiveness without directly impacting the source of truth (the event stream). Options A is incorrect because direct database updates bypass the benefits of CQRS, option C misinterprets the purpose of a handler in this context, and option D incorrectly states that immediate reaction is always best practice.
15 / 25
David: 'Hey team, I'm working on optimizing the user profile service. We're using Event Sourcing and projections to create a 'User Activity Timeline' view for each user. The event stream is growing rapidly, and the projection logic is becoming quite complex. I've been considering using a snapshot to reduce the load on the event store during queries. Does this sound like a reasonable strategy, or am I overlooking something crucial about maintaining consistency in an Event-Driven system? Specifically, I'm worried about divergence between the raw events and the timeline view.'This question assesses understanding of the purpose of snapshots in Event Sourcing. Snapshots provide a point-in-time representation of the aggregate state, allowing projections to quickly initialize without processing all historical events. The key misconception is that snapshots always increase overhead – they actually *reduce* it by providing a starting point and minimizing the need for full event replay during queries. The correct answer highlights their role in reducing query load; options B & C misrepresent snapshot usage and potential inconsistencies, while option A incorrectly states a universal performance penalty.
16 / 25
Sarah: 'Hey team, I'm struggling with the PR. The event stream for the `UserOrder` service is *massive*, and querying it directly to get a list of recent orders is taking ages! We're using an Event Sourcing pattern here, so what's the most efficient way to build this view? (Excerpt from Slack conversation)The correct answer is option 1. While indexing or batch processing might offer *some* performance gains, they don't fundamentally address the problem of a large, constantly growing event stream. A projection – a read model built from events – is precisely what Event Sourcing is designed for: to create optimized views tailored for specific query needs. This avoids overloading the core event store and maintains consistency by reacting to new events.
17 / 25
John: 'I've reviewed the PR for the `ShoppingCart` service. The team is using Event Sourcing and a projection strategy to build the real-time inventory dashboard. I noticed that the PR description mentions creating a new event handler specifically for 'InventoryUpdated' events. Is this the correct approach, or are there alternative ways to ensure consistency between the source of truth (the event stream) and the dashboard view? The PR description currently says: 'This PR implements an event handler to react to `InventoryUpdated` events in the Event Store, ensuring that the inventory dashboard reflects these changes in near real-time.'
The key misunderstanding here is that while reactive handling (an event handler) *is* a valid part of an Event Sourced system, it's not the *most* efficient or common approach for building projections. In this scenario, the team is correctly utilizing an event handler to react to `InventoryUpdated` events. However, the correct answer highlights that creating a dedicated handler guarantees consistency by directly consuming the event stream and ensuring the dashboard reflects those changes in near real-time. Options A and D suggest incorrect strategies – simply reacting isn't enough for a projection, and direct subscription without handlers would likely lead to data lag or complex logic within the dashboard itself.
18 / 25
Reviewer: 'The team's using Event Sourcing and projections for the `OrderProcessing` service. I noticed they're creating a separate *read model* derived from the event stream to power the reporting dashboard. They've described it as 'synchronizing the view with the source of truth'. Does this align with best practices in an Event-Driven Architecture, or is there a more refined approach?', (Excerpt from Code Review Comment)The core concept here is understanding how projections relate to Event Sourcing. While 'synchronizing the view' isn't incorrect in its simplest form, it doesn't fully address potential issues like eventual consistency and query optimization. Projections should be carefully designed—defining specific data transformations and update strategies—to ensure accuracy and performance. Option 0 correctly identifies this nuance; a robust projection strategy involves more than just mirroring the event stream.
19 / 25
PR Description:
"This PR introduces a new event handler named `ProcessPaymentEvent` that consumes events from the `PaymentService`'s event stream. This handler updates the `OrderStatus` in our system to 'Paid' whenever a `PaymentSuccessful` event is received. We are using CQRS, so this ensures the order details remain consistent across all systems."This question tests understanding of how event handlers fit into a CQRS architecture. The correct answer highlights that decoupling updates via an event handler is a core benefit – it allows for independent scaling and responsiveness without directly impacting the source of truth (the event stream). Options A is incorrect because direct database updates bypass the benefits of CQRS, option C misinterprets the purpose of a handler in this context, and option D incorrectly states that immediate reaction is always best practice.
20 / 25
David: 'Hey team, I'm working on optimizing the user profile service. We're using Event Sourcing and projections to create a 'User Activity Timeline' view for each user. The event stream is growing rapidly, and the projection logic is becoming quite complex. I've been considering using a snapshot to reduce the load on the event store during queries. Does this sound like a reasonable strategy, or am I overlooking something crucial about maintaining consistency in an Event-Driven system? Specifically, I'm worried about divergence between the raw events and the timeline view.'This question assesses understanding of the purpose of snapshots in Event Sourcing. Snapshots provide a point-in-time representation of the aggregate state, allowing projections to quickly initialize without processing all historical events. The key misconception is that snapshots always increase overhead – they actually *reduce* it by providing a starting point and minimizing the need for full event replay during queries. The correct answer highlights their role in reducing query load; options B & C misrepresent snapshot usage and potential inconsistencies, while option A incorrectly states a universal performance penalty.
21 / 25
Sarah: 'Hey team, I'm struggling with the PR. The event stream for the `UserOrder` service is *massive*, and querying it directly to get a list of recent orders is taking ages! We're using an Event Sourcing pattern here, so what's the most efficient way to build this view? (Excerpt from Slack conversation)The correct answer is option 1. While indexing or batch processing might offer *some* performance gains, they don't fundamentally address the problem of a large, constantly growing event stream. A projection – a read model built from events – is precisely what Event Sourcing is designed for: to create optimized views tailored for specific query needs. This avoids overloading the core event store and maintains consistency by reacting to new events.
22 / 25
John: 'I've reviewed the PR for the `ShoppingCart` service. The team is using Event Sourcing and a projection strategy to build the real-time inventory dashboard. I noticed that the PR description mentions creating a new event handler specifically for 'InventoryUpdated' events. Is this the correct approach, or are there alternative ways to ensure consistency between the source of truth (the event stream) and the dashboard view? The PR description currently says: 'This PR implements an event handler to react to `InventoryUpdated` events in the Event Store, ensuring that the inventory dashboard reflects these changes in near real-time.'
The key misunderstanding here is that while reactive handling (an event handler) *is* a valid part of an Event Sourced system, it's not the *most* efficient or common approach for building projections. In this scenario, the team is correctly utilizing an event handler to react to `InventoryUpdated` events. However, the correct answer highlights that creating a dedicated handler guarantees consistency by directly consuming the event stream and ensuring the dashboard reflects those changes in near real-time. Options A and D suggest incorrect strategies – simply reacting isn't enough for a projection, and direct subscription without handlers would likely lead to data lag or complex logic within the dashboard itself.
23 / 25
Reviewer: 'The team's using Event Sourcing and projections for the `OrderProcessing` service. I noticed they're creating a separate *read model* derived from the event stream to power the reporting dashboard. They've described it as 'synchronizing the view with the source of truth'. Does this align with best practices in an Event-Driven Architecture, or is there a more refined approach?', (Excerpt from Code Review Comment)The core concept here is understanding how projections relate to Event Sourcing. While 'synchronizing the view' isn't incorrect in its simplest form, it doesn't fully address potential issues like eventual consistency and query optimization. Projections should be carefully designed—defining specific data transformations and update strategies—to ensure accuracy and performance. Option 0 correctly identifies this nuance; a robust projection strategy involves more than just mirroring the event stream.
24 / 25
PR Description:
"This PR introduces a new event handler named `ProcessPaymentEvent` that consumes events from the `PaymentService`'s event stream. This handler updates the `OrderStatus` in our system to 'Paid' whenever a `PaymentSuccessful` event is received. We are using CQRS, so this ensures the order details remain consistent across all systems."This question tests understanding of how event handlers fit into a CQRS architecture. The correct answer highlights that decoupling updates via an event handler is a core benefit – it allows for independent scaling and responsiveness without directly impacting the source of truth (the event stream). Options A is incorrect because direct database updates bypass the benefits of CQRS, option C misinterprets the purpose of a handler in this context, and option D incorrectly states that immediate reaction is always best practice.
25 / 25
David: 'Hey team, I'm working on optimizing the user profile service. We're using Event Sourcing and projections to create a 'User Activity Timeline' view for each user. The event stream is growing rapidly, and the projection logic is becoming quite complex. I've been considering using a snapshot to reduce the load on the event store during queries. Does this sound like a reasonable strategy, or am I overlooking something crucial about maintaining consistency in an Event-Driven system? Specifically, I'm worried about divergence between the raw events and the timeline view.'This question assesses understanding of the purpose of snapshots in Event Sourcing. Snapshots provide a point-in-time representation of the aggregate state, allowing projections to quickly initialize without processing all historical events. The key misconception is that snapshots always increase overhead – they actually *reduce* it by providing a starting point and minimizing the need for full event replay during queries. The correct answer highlights their role in reducing query load; options B & C misrepresent snapshot usage and potential inconsistencies, while option A incorrectly states a universal performance penalty.
Frequently Asked Questions
What does the "Event Sourcing & CQRS — Vocabulary — Event-Driven Architecture | CoderLingo" exercise cover?
Learn event sourcing and CQRS vocabulary: event store, projections, command handlers, and snapshots.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
How many questions are in "Event Sourcing & CQRS — Vocabulary — Event-Driven Architecture | CoderLingo"?
This exercise has 25 questions. Each one gives instant feedback with an explanation, so you can see exactly why an answer is right or wrong.
Do I need to create an account to save my progress?
No account is required. The progress bar and score are tracked in your browser for the current session -- the exercise is designed to be a quick, repeatable drill rather than something you resume later.
What happens if I get an answer wrong?
You'll see the correct answer highlighted immediately, along with a short explanation of why it's correct. Wrong answers aren't penalized beyond your score, and you can keep going through every question.
How is this exercise different from reading an article?
Articles explain vocabulary and concepts through prose, while exercises like this one are interactive drills -- multiple-choice questions -- that test and reinforce your recall of specific terms and phrasing.
Can I retry this exercise?
Yes -- use the "Try again" button on the results screen to reset your score and go through all the questions again from the start.
Where can I find more Event-Driven Architecture Language exercises?
Browse the full Event-Driven Architecture Language hub for related drills, or check the site-wide exercises index for other IT English topics.
Is this exercise suitable for beginners?
This exercise assumes basic familiarity with IT terminology. If a term feels unfamiliar, check the site Glossary for a plain-English definition before attempting the questions.
How often is new content like this published?
New exercises are added regularly across all categories, alongside new vocabulary sets and articles. Check back on the exercises hub to see what's new.