5 exercises — Practice the language used when discussing EDA design decisions: eventual consistency, outbox pattern, and trade-off vocabulary.
0 / 14 completed
1 / 14
A colleague says: "The read model is eventually consistent." What does this mean in an EDA context?
In event-driven systems, the read model is updated asynchronously by processing events — there is a delay between a write (event emitted) and the read model reflecting it. This is eventual consistency: the lag exists but the system converges.
2 / 14
The outbox pattern solves which problem?
The outbox pattern: within the same DB transaction, write your domain changes AND write the event to an 'outbox' table. A separate poller/CDC process reads the outbox and publishes to the broker. This avoids the 'dual-write' reliability problem.
3 / 14
When comparing EDA to request-response, which sentence correctly states an EDA advantage?
Loose coupling is a core EDA benefit — the producer emits an event without knowing who subscribes. New consumers can be added without changing the producer. This contrasts with REST where the client must know the server's endpoint.
4 / 14
Fill in the blank: "A choreography saga gives us more autonomy but makes it harder to ___ the overall flow."
With choreography, the saga logic is distributed across services — there is no single place to inspect the state of a running saga. 'Trace' (or 'track', 'observe') is the vocabulary for understanding what has happened and where a distributed flow currently is.
5 / 14
Which sentence correctly uses tight coupling as a design concern?
Tight coupling is a design smell in distributed systems — when Service A knows too much about Service B's internals (schema, endpoints), any change to B breaks A. EDA addresses this by communicating through events with stable schemas.
6 / 14
Reviewer: 'I'm concerned about the latency of this event. We're getting a lot of 'Failed' events from the order processing service, and it's impacting our dashboards. What are some strategies to mitigate that?'
Which of the following approaches would be MOST effective in addressing this reviewer's concern within an Event-Driven Architecture?
The reviewer highlights latency issues caused by failed events. A 'dead letter queue' (DLQ) is a standard EDA practice for handling transient failures without blocking downstream consumers. This allows the failing service to be investigated independently and doesn't impact the overall event flow. Batching events, as option D suggests, can reduce frequency but doesn't directly address the root cause of failed events; retry mechanisms (option A) can lead to infinite loops if failures are persistent, and polling (option C) defeats the asynchronous nature of EDA.
7 / 14
Reviewer: 'I'm concerned about the latency of this event. We're getting a lot of 'Failed' events from the order processing service, and it's impacting our dashboards. What are some strategies to mitigate that?'
Which of the following approaches would be MOST effective in addressing this reviewer's concern within an Event-Driven Architecture?
The reviewer highlights latency issues caused by failed events. A 'dead letter queue' (DLQ) is a standard EDA practice for handling transient failures without blocking downstream consumers. This allows the failing service to be investigated independently and doesn't impact the overall event flow. Batching events, as option D suggests, can reduce frequency but doesn't directly address the root cause of failed events; retry mechanisms (option A) can lead to infinite loops if failures are persistent, and polling (option C) defeats the asynchronous nature of EDA.
8 / 14
Reviewer: 'I'm concerned about the latency of this event. We're getting a lot of 'Failed' events from the order processing service, and it's impacting our dashboards. What are some strategies to mitigate that?'
Which of the following approaches would be MOST effective in addressing this reviewer's concern within an Event-Driven Architecture?
The reviewer highlights latency issues caused by failed events. A 'dead letter queue' (DLQ) is a standard EDA practice for handling transient failures without blocking downstream consumers. This allows the failing service to be investigated independently and doesn't impact the overall event flow. Batching events, as option D suggests, can reduce frequency but doesn't directly address the root cause of failed events; retry mechanisms (option A) can lead to infinite loops if failures are persistent, and polling (option C) defeats the asynchronous nature of EDA.
9 / 14
Reviewer: 'I'm concerned about the latency of this event. We're getting a lot of 'Failed' events from the order processing service, and it's impacting our dashboards. What are some strategies to mitigate that?'
Which of the following approaches would be MOST effective in addressing this reviewer's concern within an Event-Driven Architecture?
The reviewer highlights latency issues caused by failed events. A 'dead letter queue' (DLQ) is a standard EDA practice for handling transient failures without blocking downstream consumers. This allows the failing service to be investigated independently and doesn't impact the overall event flow. Batching events, as option D suggests, can reduce frequency but doesn't directly address the root cause of failed events; retry mechanisms (option A) can lead to infinite loops if failures are persistent, and polling (option C) defeats the asynchronous nature of EDA.
10 / 14
During a standup meeting, Sarah mentions our new e-commerce platform utilizes an Event-Driven Architecture. When she says 'eventual consistency,' what is the most accurate interpretation in this context?
A) Data is immediately and perfectly consistent across all systems.
B) There's a deliberate delay in data propagation, accepting some inconsistencies for performance reasons.
C) All events are synchronously processed, guaranteeing immediate updates.
D) Eventual consistency refers solely to database transactions.
Eventual consistency is a key characteristic of EDA. It acknowledges that changes propagate through the system over time due to asynchronous event processing. Option B accurately describes this trade-off: prioritizing speed and scalability by accepting temporary inconsistencies. Options A and C are incorrect as they imply immediate, perfect synchronization.
11 / 14
Reviewer comment: 'This PR introduces an event to update user profile data. However, the event doesn't include any error handling or retry logic. What's a good approach to handle potential failures during event processing?' Consider the following options:
A) Ignore failed events and proceed with the next one.
B) Implement a dead-letter queue for failed events to be investigated later.
C) Immediately rollback the entire transaction upon any event failure.
D) Log the error but continue processing, assuming no other events are affected.
Handling failures in EDA is crucial. A dead-letter queue provides a mechanism to capture problematic events for later analysis and potential reprocessing without disrupting the overall system flow. Options A and D represent poor practices, while option C introduces unnecessary complexity and risk.
12 / 14
Mark from Operations sends this Slack message: 'We're seeing a spike in 'Order Placed' events from the payment service. The read model isn't reflecting these changes quickly enough. What EDA concept could explain this?'
Consider the following options:
A) High event throughput.
B) Asynchronous communication and eventual consistency.
C) Tight coupling between services.
D) Request-response architecture.
The core issue is 'eventual consistency.' This describes the trade-off inherent in EDA where data updates are propagated asynchronously. Asynchronous communication allows for high throughput but introduces a delay between event emission and read model update. Option B encapsulates this concept perfectly.
13 / 14
You're writing the PR description for a new service that publishes 'Customer Created' events. The description should briefly explain the architecture and highlight a key decision.
Which of these sentences best captures this?
A) 'This service directly updates the customer database with every new user.'
B) 'The service publishes events to trigger asynchronous updates in downstream services, reflecting eventual consistency.'
C) 'The service uses synchronous calls to update all relevant systems.'
D) 'We've implemented a simple API endpoint for creating customers.'
This description needs to accurately represent the EDA approach. Publishing events allows downstream services to handle updates asynchronously, acknowledging eventual consistency and decoupling the services. Options A and C are incorrect because they describe synchronous updates which is not an EDA principle.
14 / 14
A team is designing a new e-commerce system using Event-Driven Architecture. They need to choose between Saga patterns and Choreography patterns. Which statement best describes the key difference?
A) Sagas use a central orchestrator, while Choreography relies on loose coupling.
B) Choreography patterns are simpler to implement than Sagas.
C) Sagas provide more control over the overall flow but can become complex.
The fundamental difference lies in their approach to coordination. Saga patterns use a central orchestrator to manage the sequence of steps, offering more control and handling compensation logic. Choreography relies on events being published and consumed by independent services, promoting loose coupling but requiring careful design for error handling.
What does the "Discussing EDA Architecture Trade-offs — Language — Event-Driven Architecture | CoderLingo" exercise cover?
Practice the language used when discussing EDA design decisions: eventual consistency, outbox pattern, and trade-off vocabulary.
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 "Discussing EDA Architecture Trade-offs — Language — Event-Driven Architecture | CoderLingo"?
This exercise has 14 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.