Event-Driven Architecture — Vocabulary and Communication
Learn vocabulary for event-driven architecture: events vs. commands, sagas, outbox pattern, and event sourcing.
0 / 16 completed
1 / 16
What is the difference between an 'event' and a 'command' in event-driven architecture?
Event: 'OrderPlaced' — something already happened, the publisher doesn't care who handles it. Command: 'ProcessPayment' — an instruction to a specific service to do something. Events decouple publisher and subscriber; commands create a direct relationship. Event-driven systems prefer events for loose coupling; commands for explicit orchestration.
2 / 16
What is the 'Saga pattern' in microservices vocabulary?
Saga: distributed transactions without a two-phase commit. Choreography-based saga: each service publishes events that trigger the next service. Orchestration-based saga: a central coordinator tells each service what to do. If any step fails, compensating transactions undo previous steps. Example: Order placement saga — PlaceOrder → ReserveInventory → ChargPayment → ConfirmOrder.
3 / 16
What is the 'outbox pattern' in microservices vocabulary?
Outbox pattern solves the dual-write problem: you cannot atomically write to a database AND publish to Kafka/RabbitMQ. Solution: write to both the business table AND an 'outbox' table in one database transaction, then a Debezium CDC process reads the outbox table and publishes to the message broker. This guarantees at-least-once delivery without distributed transactions.
4 / 16
What is 'event sourcing' in distributed systems vocabulary?
Event sourcing: instead of storing 'balance = 500', store [AccountOpened(initial=1000), Deposited(200), Withdrawn(700)]. The current state (balance=500) is derived by replaying events. Benefits: complete audit history, ability to rebuild state at any point in time, enables event-driven integration. Trade-off: query complexity (need projections/read models).
5 / 16
What is 'at-least-once delivery' vs. 'exactly-once delivery' in messaging vocabulary?
At-least-once: the broker retries until the consumer acknowledges — but network failures can cause the same message to be delivered twice. Consumers must be idempotent. Exactly-once: extremely difficult to guarantee across distributed systems; Kafka Transactions attempt this for Kafka-to-Kafka flows. In practice, most systems implement at-least-once with idempotent consumers.
6 / 16
Sarah from the Payments team sent this Slack message: 'The OrderCreated event triggered a cascade of actions. We need to ensure the downstream services are handling failures gracefully – specifically, retries and idempotency. It's crucial we monitor the queue depth for PaymentProcessed events.' What does Sarah primarily mean when she discusses 'idempotency' in this context?
Sarah is referring to a key principle in distributed systems: idempotency. It ensures that processing the same event multiple times has the same effect as processing it just once – preventing unintended consequences like duplicate transactions or incorrect data updates. Option D captures the core meaning of idempotency; options B and C relate to different aspects of event handling.
7 / 16
Mark left this comment on a code review for an API endpoint that publishes events: 'The use of a message broker like Kafka is good, but we need to consider how the consumer handles situations where the event isn't immediately processed. What's the best approach here?' What does Mark likely want to discuss regarding event consumption?
Mark is highlighting the importance of resilience in event processing. Dead-letter queues are a standard pattern for handling events that cannot be processed successfully due to errors or transient issues. This allows consumers to gracefully manage failures and prevent data corruption – options A and B describe related concepts but don't directly address Mark's concern about robust error handling.
8 / 16
During a standup meeting, David from the Inventory team described using an 'event hub' to decouple his service from the Order Management system. He explained that when a new order is placed, an 'OrderPlaced' event is published. Which of the following BEST describes the primary purpose of this 'event hub'?
An event hub serves as an intermediary to decouple the systems. It allows the Order Management service to publish events without needing direct knowledge of the Inventory service's structure or location. This promotes loose coupling and asynchronous processing – key principles in event-driven architecture. The other options represent incorrect interpretations of the role of an event hub.
9 / 16
You're reviewing a PR that introduces support for 'Idempotent Consumers' in a microservice. The commit message states: 'Ensuring consumers don't process the same event multiple times to prevent unintended side effects.' What is the PRIMARY benefit of using idempotent consumers in an event-driven system?
Idempotency is crucial for handling unreliable messaging. When a message is delivered multiple times (due to retries or network issues), an idempotent consumer will process it only once, preventing unintended side effects like duplicate updates or incorrect calculations. This ensures data consistency and reliability in the face of failures – a core concern in distributed systems.
10 / 16
During a discussion about API design, Elena from the UX team mentions 'event schemas'. She explains that these schemas define the structure and data contained within each event. What is the MOST important reason for using well-defined event schemas in an event-driven architecture?
Well-defined event schemas are fundamental to interoperability. They provide a standard format for events, allowing different consumers to understand and correctly interpret the data without requiring complex mapping or transformation logic. This is crucial for decoupling services and enabling independent evolution of systems – a key benefit of event-driven architecture.
11 / 16
You are designing an event sourcing system. You want to ensure that you can reconstruct the state of your application at any point in time by analyzing all events. Which of the following best describes the core principle behind 'Event Sourcing'?
Event sourcing fundamentally differs from traditional persistence. Instead of storing the current state directly, it records every change as an immutable event. This allows you to replay these events to reconstruct the application's state at any point in time – providing a complete audit trail and enabling features like time-travel debugging and historical reporting.
12 / 16
Mark, a senior developer on the Shipping team, sent this Slack message: 'The OrderShipped event triggered a chain of updates to our fulfillment system. We need to monitor for dropped events and implement dead-letter queues – essentially, a place where problematic events are stored for investigation.' Considering Mark's message, what is the primary purpose of a 'dead-letter queue' in an event-driven architecture?
Mark is highlighting the need for resilience. Dead-letter queues are designed specifically for handling events that fail to be processed—this allows investigation and recovery rather than simply assuming failure. Options A and C suggest automated attempts which could exacerbate issues, while option D describes a data store, not the queue's function.
13 / 16
Elena from the Customer Support team is describing an event schema for a 'CustomerSignedUp' event. She says: 'The schema defines the fields like `userId`, `email`, and `signupTimestamp`. Maintaining this schema ensures consistency across all services consuming the event.' What does 'event schema' primarily achieve in an event-driven system?
Elena's explanation centers around consistency and interoperability. An 'event schema' defines the structure of an event – the fields and their expected data types – ensuring that different services can understand and process the same event without issues. Option A is incorrect as schemas don't dictate processing routes; option C describes notification systems, and D refers to security policies.
14 / 16
Mark from the Shipping team sent this Slack message: 'The OrderShipped event triggered a chain of updates to our fulfillment system. We need to monitor for dropped events and implement dead-letter queues.' Which of the following best describes the purpose of a dead-letter queue in this context?
A. To store events that are successfully processed by consumers. B. To handle events that cannot be delivered or processed after multiple retries, potentially indicating a problem with the event itself or the consumer. C. To prioritize high-volume events for faster processing. D. To provide a central location for viewing all event data in real-time.
Dead-letter queues are crucial for handling failed events within an event-driven system. They act as a safety net, capturing messages that couldn't be processed after several attempts, allowing developers to investigate and resolve the underlying issue – this is distinct from simply logging successful events or prioritizing data flow.
15 / 16
Elena from the Customer Support team is describing an event schema for a 'CustomerSignedUp' event. She says: 'The schema defines the fields like `userId`, `email`, and `signupTimestamp`. Maintaining this schema ensures …
A. Automatic generation of new events based on existing data. B. Consistent data structure across all services consuming the event, preventing integration issues and ensuring reliable processing. C. The ability to directly query the event data for historical analysis without reconstructing the entire event log. D. That all consumers will automatically retry failed events.
Event schemas are vital for interoperability in event-driven architectures. They enforce a standardized format, ensuring that different services can reliably consume and process the same event data – preventing errors caused by mismatched data structures is key.
16 / 16
Sarah from the Payments team sent this Slack message: 'The OrderCreated event triggered a cascade of actions. We need to ensure the downstream services are handling failures gracefully – specifically, retries and idempotency…'. Which of the following best describes idempotency in relation to event processing?
A. The ability for an event consumer to process an event multiple times without unintended side effects. B. A mechanism for automatically detecting and resolving failed events. C. A technique for ensuring that all events are delivered at least once. D. The process of verifying the integrity of an event's data.
Idempotency is a critical pattern in distributed systems, particularly when dealing with eventual consistency and potential message duplication. It ensures that processing the same event multiple times has the same effect as processing it once – preventing unintended consequences.
What will I practise in "Event-Driven Architecture — Vocabulary and Communication"?
This module focuses on Microservices Language — real workplace phrasing you'll use on the job. It contains 16 scenario-based multiple-choice questions with instant feedback.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account or sign-up required.
How many questions does this exercise have?
This module includes 16 questions. Each one gives an immediate right/wrong result plus a full explanation of the correct phrasing.
What happens if I answer a question incorrectly?
You'll see the correct answer highlighted straight away, along with a plain-English explanation of why it's right and why the other options don't fit — mistakes are part of the learning here.
Can I retry the exercise if I want a better score?
Yes — use the 'Try again' button on the results screen to reset your score and go through the questions again. There's no limit on attempts.
Who is this Microservices Language exercise for?
It's aimed at IT professionals with working English who want to sound more natural and precise around microservices language — useful whether you're preparing for real conversations at work or just building confidence with the vocabulary.
Do I need an account to track my progress?
No account is needed. Your progress through the exercise is tracked locally in your browser for the current session, and you can replay the module at any time.
How is this different from reading a blog article?
This exercise is an interactive drill that tests and reinforces specific phrasing through multiple-choice questions with instant feedback, while blog articles explain concepts and vocabulary in prose. The two work well together.
Where can I find more Microservices Language exercises?
See the Microservices Language hub for more modules like this one, or browse the full Exercises page for other IT-English topics.
Can I complete this exercise on my phone?
Yes — every exercise on CoderSlingo is fully responsive and works on phones and tablets, so you can practise anywhere.