5 exercises — Learn domain event naming, schema vocabulary, thin vs fat events, and integration vs domain events.
0 / 20 completed
1 / 20
Your team debates whether to use a thin event or a fat event. Which statement is correct?
Thin events (reference events) force consumers to make additional API calls to get data, reducing payload size but adding coupling. Fat events (notification events with payload) reduce coupling but increase payload size and schema surface.
2 / 20
Which event name follows correct domain event naming conventions?
Domain events are named in the past tense using PascalCase: 'OrderShipped', 'UserRegistered', 'PaymentDeclined'. Present/future tense names confuse events with commands; verb-first names ('ShipOrder') are commands.
3 / 20
A correlation ID in an event schema is used to:
A correlation ID (or trace ID) is set at the start of a business process and propagated through all events and service calls. It enables end-to-end tracing — you can find all events from a single user request.
4 / 20
What distinguishes a domain event from an integration event?
A domain event represents something meaningful within a bounded context — it uses the domain's ubiquitous language. Integration events cross context boundaries and must be more stable, versioned, and deliberately designed.
5 / 20
Fill in the blank: "We discovered schema drift — the ___ had changed without updating the consuming services."
Schema drift in event-driven systems occurs when the event schema (field names, types, required fields) changes in the producing service without corresponding updates to consumers — breaking the event contract between services.
6 / 20
Reviewer: 'The `AccountCreated` event seems a little verbose. We're sending a lot of data about the customer – address, phone number… maybe we should consider splitting this into smaller events like `CustomerRegistered` and `AddressProvided`. What's the best way to respond to this feedback in our PR description?'
Which option accurately addresses the reviewer's suggestion while maintaining good event design principles?
The reviewer's comment highlights the principle of domain-driven design: events should be focused on specific business capabilities. While splitting events can indeed reduce coupling and complexity in some scenarios, simply doing so without considering downstream consumers' capacity is a bad idea. The correct response acknowledges this by stating that splitting events based on business capability is valid but emphasizes the importance of managing potential increased event volume and complexity. Options B and C misinterpret the reviewer's suggestion or ignore crucial design considerations.
7 / 20
Reviewer: 'The `AccountCreated` event seems a little verbose. We're sending a lot of data about the customer – address, phone number… maybe we should consider splitting this into smaller events like `CustomerRegistered` and `AddressProvided`. What's the best way to respond to this feedback in our PR description?'
Which option accurately addresses the reviewer's suggestion while maintaining good event design principles?
The reviewer's comment highlights the principle of domain-driven design: events should be focused on specific business capabilities. While splitting events can indeed reduce coupling and complexity in some scenarios, simply doing so without considering downstream consumers' capacity is a bad idea. The correct response acknowledges this by stating that splitting events based on business capability is valid but emphasizes the importance of managing potential increased event volume and complexity. Options B and C misinterpret the reviewer's suggestion or ignore crucial design considerations.
8 / 20
Reviewer: 'The `AccountCreated` event seems a little verbose. We're sending a lot of data about the customer – address, phone number… maybe we should consider splitting this into smaller events like `CustomerRegistered` and `AddressProvided`. What's the best way to respond to this feedback in our PR description?'
Which option accurately addresses the reviewer's suggestion while maintaining good event design principles?
The reviewer's comment highlights the principle of domain-driven design: events should be focused on specific business capabilities. While splitting events can indeed reduce coupling and complexity in some scenarios, simply doing so without considering downstream consumers' capacity is a bad idea. The correct response acknowledges this by stating that splitting events based on business capability is valid but emphasizes the importance of managing potential increased event volume and complexity. Options B and C misinterpret the reviewer's suggestion or ignore crucial design considerations.
9 / 20
Reviewer: 'The `AccountCreated` event seems a little verbose. We're sending a lot of data about the customer – address, phone number… maybe we should consider splitting this into smaller events like `CustomerRegistered` and `AddressProvided`. What's the best way to respond to this feedback in our PR description?'
Which option accurately addresses the reviewer's suggestion while maintaining good event design principles?
The reviewer's comment highlights the principle of domain-driven design: events should be focused on specific business capabilities. While splitting events can indeed reduce coupling and complexity in some scenarios, simply doing so without considering downstream consumers' capacity is a bad idea. The correct response acknowledges this by stating that splitting events based on business capability is valid but emphasizes the importance of managing potential increased event volume and complexity. Options B and C misinterpret the reviewer's suggestion or ignore crucial design considerations.
10 / 20
Sarah, a backend engineer, is discussing event design with the team. 'We should send all customer details – name, email, address – in a single event.' David, a senior developer, responds: 'That's a fat event! It increases coupling and makes it harder to evolve our system. Shouldn't we consider splitting this into smaller events?' Which statement best reflects the discussion about domain events?
This question tests understanding of 'fat' vs. 'thin' events. It frames the discussion within a realistic scenario (a debate) and highlights the potential negative consequences of sending too much data in one event – increased coupling and reduced flexibility. Option A incorrectly focuses on business impact; option C is overly simplistic and ignores architectural concerns; option D prioritizes performance over architecture.
11 / 20
You're reviewing a Slack message from the DevOps team regarding a new service. The message reads: 'New event: `UserCreatedEvent` triggered when a user signs up. Payload includes: `userId`, `email`, `firstName`, `lastName`. Schema version 1.' Which of the following best describes the purpose of including 'Schema version 1' in this event?
This question assesses understanding of schema evolution in event-driven systems. Including 'Schema version 1' is crucial for managing changes to the event payload over time. Consumers can then handle different versions gracefully, preventing breaking changes when the event structure evolves (this is a core concept in event-driven architecture).
12 / 20
During a code review of an e-commerce service, Mark points out: 'The `OrderPlaced` event doesn't include the shipping address. We should add it to ensure downstream services can fulfill the order.' What is the *primary* reason for including the shipping address in this event?
This question focuses on the role of events in propagating data. The shipping address is a critical piece of information required by fulfillment systems to complete the order process. Including it ensures downstream services have everything they need without requiring additional queries or complex integration logic. It's about reducing coupling.
13 / 20
You're designing an event system for a microservices architecture. A service publishes an 'InventoryUpdatedEvent'. Another service consumes this event and updates its database. The consumer service experiences intermittent failures when processing the `InventoryUpdatedEvent`. What is the *most* likely cause?
This scenario tests understanding of potential integration challenges in event-driven systems. If consumers aren't designed to handle evolving event schemas (different versions), they can break when the publisher changes the payload structure. This is a common source of problems and highlights the need for versioning and robust error handling in consumer services.
14 / 20
During a standup update, Alex says: 'We're using event naming conventions that follow the pattern `[Domain]EventName`. This helps us clearly understand where events originate and their purpose.' Which of the following is most accurate regarding this approach?
The stated naming convention (e.g., `[Domain]EventName`) is a common and valuable practice in event-driven architecture. It enforces loose coupling by clearly defining the origin of an event (the domain) and its purpose. This allows services to react appropriately based on the event type, regardless of implementation details. Options A and C misrepresent the benefits; option B is overly restrictive.
15 / 20
You are designing an event schema for a payment service. Which of the following best describes the purpose of including a correlation ID in each event?
A correlation ID is a unique identifier assigned to a series of related events. It allows developers to trace the flow of a single transaction or operation across multiple services involved in the event-driven architecture. This simplifies debugging and troubleshooting complex issues that arise from asynchronous communication, providing valuable context for identifying root causes. Options A and C are less relevant to the core function of correlation IDs.
16 / 20
Sarah's team is designing an event system for a new e-commerce platform. They've decided to use the naming convention `OrderCreatedEvent`. Which of the following statements best describes the purpose of including a 'transactionId' field within this event schema?
The primary purpose of a `transactionId` in an event schema is to uniquely identify the transaction being processed. This allows for tracking and reconciliation across systems involved in the order lifecycle – crucial for auditing and resolving discrepancies. The other options relate to different data points that might be captured within events but not the core function of identifying the underlying transaction.
17 / 20
Reviewer: 'We need a way to track event delivery failures. Adding an `eventProcessed` boolean flag to each event schema will help us monitor which events have been successfully processed.' Which of the following describes the *most* effective use of this flag?
The `eventProcessed` flag is specifically designed to track the status of an event after it's been consumed by a downstream service. It's a key metric for monitoring the health and reliability of the event pipeline. While retry mechanisms might use this data, its primary role is simply indicating successful processing.
18 / 20
During a Slack discussion about event design, a developer asks: 'How do we ensure that events are consumed in the correct order when multiple services might trigger related events?' Which of the following approaches is *most* appropriate?
While message queues can enforce ordering, it's often complex and introduces bottlenecks. Idempotency addresses conflicts but doesn't guarantee order. Circuit breakers are for resilience, not sequencing. The most robust approach is to explicitly define dependencies between events and ensure consumers subscribe in the correct order – a fundamental aspect of event-driven architecture.
19 / 20
A code review comment reads: 'The `ProductAddedToCart` event doesn't include any information about the product itself. We should add a reference to the Product entity to allow downstream services to easily retrieve product details.' What is the *primary* benefit of including a product reference within this event?
The core benefit is data locality. Embedding a reference to the Product entity avoids the need for downstream services to perform costly joins or lookups to retrieve product details – significantly improving performance and reducing coupling between services. The other options represent secondary benefits, not the primary reason.
20 / 20
You're designing an event schema for a microservice responsible for managing user profiles. Which of the following is the *most* important consideration when determining the structure and content of this event?
The primary consideration is ensuring that the event contains *enough* information for downstream services to correctly update the user profile. While payload size matters, it's secondary to accuracy. Compatibility and schema formats are important but derive from this core requirement – you need the data to do what the event represents.
What does the "Domain Events — Vocabulary & Naming Conventions — Event-Driven Architecture | CoderLingo" exercise cover?
Learn domain event naming, schema vocabulary, thin vs fat events, and integration vs domain events.
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 "Domain Events — Vocabulary & Naming Conventions — Event-Driven Architecture | CoderLingo"?
This exercise has 20 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.