What is the key difference between a topic and a queue in messaging?
In classic messaging terms: queues (point-to-point) deliver each message to one consumer; topics (publish-subscribe) deliver each message to all subscribers. Kafka uses 'topic' but consumer groups provide queue-like semantics within a group.
2 / 14
In Kafka, a consumer group works as follows:
Within a consumer group, each partition is consumed by exactly one consumer. This enables parallel processing — scale by adding consumers up to the partition count. Multiple groups can each receive all messages independently.
3 / 14
A message is sent to the dead-letter queue (DLQ) when:
DLQs capture 'poison messages' — messages that fail repeatedly (due to bad format, processing errors, etc.) so they don't block the queue. Ops teams can inspect, replay, or discard DLQ messages after root-cause analysis.
4 / 14
Your system uses at-least-once delivery. This means:
At-least-once guarantees no message loss but allows duplicates (e.g., if acknowledgment fails after processing). Consumers must be idempotent — processing the same message twice must produce the same result as processing it once.
5 / 14
In Kafka, the offset is:
Each message in a Kafka partition has a unique, sequential offset. Consumers commit their offset to record progress — if a consumer restarts, it resumes from the last committed offset, enabling at-least-once or exactly-once processing.
6 / 14
Code Review Comment
During a code review for the new order processing service, Sarah points out this line:
`'This queue handles asynchronous event notifications related to order status changes. Producers publish messages to the order_status_changed topic, and consumers subscribe to it via RabbitMQ.'`
Which of the following best describes Sarah's statement regarding *topics* and *queues* in this context?
Sarah's comment accurately describes the distinct roles of topics and queues in an event-driven architecture using RabbitMQ. Topics act as labels or categories to which producers publish messages; they determine *how* messages are routed. The queue is where those messages are physically stored, processed, and consumed by subscribers. Option A correctly identifies these distinctions, while the other options misrepresent the relationship – queues aren't simply containers but rather the infrastructure that enables message routing based on topic subscriptions.
7 / 14
Code Review Comment
During a code review for the new order processing service, Sarah points out this line:
`'This queue handles asynchronous event notifications related to order status changes. Producers publish messages to the order_status_changed topic, and consumers subscribe to it via RabbitMQ.'`
Which of the following best describes Sarah's statement regarding *topics* and *queues* in this context?
Sarah's comment accurately describes the distinct roles of topics and queues in an event-driven architecture using RabbitMQ. Topics act as labels or categories to which producers publish messages; they determine *how* messages are routed. The queue is where those messages are physically stored, processed, and consumed by subscribers. Option A correctly identifies these distinctions, while the other options misrepresent the relationship – queues aren't simply containers but rather the infrastructure that enables message routing based on topic subscriptions.
8 / 14
Code Review Comment
During a code review for the new order processing service, Sarah points out this line:
`'This queue handles asynchronous event notifications related to order status changes. Producers publish messages to the order_status_changed topic, and consumers subscribe to it via RabbitMQ.'`
Which of the following best describes Sarah's statement regarding *topics* and *queues* in this context?
Sarah's comment accurately describes the distinct roles of topics and queues in an event-driven architecture using RabbitMQ. Topics act as labels or categories to which producers publish messages; they determine *how* messages are routed. The queue is where those messages are physically stored, processed, and consumed by subscribers. Option A correctly identifies these distinctions, while the other options misrepresent the relationship – queues aren't simply containers but rather the infrastructure that enables message routing based on topic subscriptions.
9 / 14
Code Review Comment
During a code review for the new order processing service, Sarah points out this line:
`'This queue handles asynchronous event notifications related to order status changes. Producers publish messages to the order_status_changed topic, and consumers subscribe to it via RabbitMQ.'`
Which of the following best describes Sarah's statement regarding *topics* and *queues* in this context?
Sarah's comment accurately describes the distinct roles of topics and queues in an event-driven architecture using RabbitMQ. Topics act as labels or categories to which producers publish messages; they determine *how* messages are routed. The queue is where those messages are physically stored, processed, and consumed by subscribers. Option A correctly identifies these distinctions, while the other options misrepresent the relationship – queues aren't simply containers but rather the infrastructure that enables message routing based on topic subscriptions.
10 / 14
You're leading a discussion on implementing an event-driven architecture. A junior developer asks: 'What's the main benefit of using a message broker compared to directly calling services?'
The core benefit of a message broker is decoupling. This means services don't need to know about each other directly, enabling asynchronous processing and resilience. Batching reduces latency but doesn't address the fundamental issue of loose coupling. Data consistency is typically managed within the messaging system itself rather than enforced by the broker.
11 / 14
Sarah, a backend engineer, is explaining the concept of a 'dead letter queue' (DLQ) to a new team member. She says: 'If a message cannot be processed after a certain number of attempts, it's moved to the DLQ for investigation.' What is the PRIMARY purpose of a DLQ?
The DLQ serves as a safety net for messages that consistently fail processing. While it might involve some retry attempts (option 1), its main function is to isolate and prevent permanent loss of data due to persistent errors. Discarding messages (option 4) would be undesirable.
12 / 14
During a standup meeting, David mentions his team is using 'at-least-once' delivery for events. What does this typically imply about potential data duplication?
'At-least-once' delivery guarantees that a message will be received at least once. This inherently allows for potential duplication because the consumer might reprocess the message if it encounters an error during processing. Idempotent consumers are crucial in this scenario (option 2).
13 / 14
You're reviewing a Slack message from the DevOps team regarding a new monitoring system: 'We're using Kafka to stream metrics data in real-time.' What is Kafka primarily responsible for in this context?
Kafka's core strength is its ability to handle real-time data streams. It acts as a distributed, durable message broker that facilitates high throughput and fault tolerance – perfect for streaming metrics data. It doesn't store historical data or directly generate alerts (options 1 & 3).
14 / 14
A developer is describing a PR change to the team: 'We've added a new producer that publishes order status updates as events to our message queue.' What does 'producer' refer to in this context?
In an event-driven architecture, a producer is responsible for creating and sending events (messages) to a message broker or queue. The consumer then processes these events. This aligns with the overall flow of event publishing and consumption.
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
How many questions are in "Message Brokers & Queues — Vocabulary — 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.