Understand at-most-once, at-least-once, and exactly-once delivery semantics in streaming systems.
0 / 10 completed
1 / 10
At-most-once delivery means:
At-most-once prioritises avoiding duplicates over guaranteeing delivery — messages may be lost if the consumer fails before acknowledging.
2 / 10
At-least-once delivery means:
At-least-once guarantees no message is lost, but retries may cause duplicates — consumers must be idempotent or deduplicate manually.
3 / 10
An 'idempotent consumer' is one that:
An idempotent consumer handles duplicate deliveries safely — applying the same event multiple times produces the same final state.
4 / 10
Exactly-once semantics in Kafka is achieved through:
Kafka exactly-once semantics (EOS) requires transactional producers (atomic write-and-commit) combined with consumers reading only committed data.
5 / 10
The term 'deduplication key' in streaming systems refers to:
A deduplication key (often a message ID or event UUID) allows downstream systems to detect and drop messages they have already processed.
6 / 10
Review Comment: 'The API response for user creation returned a 429 Too Many Requests. I've added retry logic with exponential backoff to the client code, but I'm concerned about potential throttling by the backend service. Should we implement a circuit breaker pattern here?'
This scenario tests understanding of delivery guarantees in the context of a code review. A circuit breaker isn't just about retry logic; it actively prevents cascading failures by temporarily stopping requests when the backend becomes unavailable. The 429 response indicates a systemic issue that needs proactive management beyond simple retries, highlighting the importance of considering service-level agreements (SLAs) and potential rate limiting.
7 / 10
Slack Message: 'Hey team, just confirming that the nightly data pipeline should reliably deliver at least one copy of each processed record to our analytics database. We're aiming for 99.99% delivery at-least-once.'
This question focuses on the core meaning of 'at-least-once' delivery. It's critical to understand that this doesn't guarantee *exactly* one copy or any particular order; it simply guarantees that every message is delivered at least once. The 99.99% reliability target reflects an acceptance of potential duplicates in pursuit of overall high availability.
8 / 10
PR Description: 'Implemented a new idempotency key generation strategy for the order processing service. Each order now includes a UUID as a deduplication key. This ensures that if an order is processed multiple times due to network issues, only one instance will be created, preventing duplicate orders.'
This question explores the concept of idempotency. An 'idempotent consumer' is defined by its logic—it should handle duplicate requests in a way that produces the same result as a single request. The deduplication key (UUID in this case) is simply a mechanism to *detect* duplicates and prevent further processing, but it's not the core guarantee itself.
This question presents an API response that reveals how 'exactly-once' semantics are implemented. Kafka transactions provide this guarantee by ensuring that either all operations within a transaction succeed or none do, preventing partial processing and potential data inconsistencies. The key is understanding the *mechanism* behind the semantic claim.
10 / 10
Standup Update: 'We've switched to using a composite key of user ID and event type as a deduplication key in our streaming platform. This should help prevent duplicate events from being processed if there are transient network issues.'
This question tests understanding of deduplication keys within streaming systems. A composite key (user ID + event type) is more effective than a single field because it uniquely identifies each distinct event stream. The consumer's logic still plays a vital role in correctly interpreting and handling the key to ensure idempotency.
What will I learn from the "Delivery Guarantees Vocabulary" exercise?
Understand at-most-once, at-least-once, and exactly-once delivery semantics in streaming systems.
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 required.
How many questions are in this exercise?
This set contains 10 multiple-choice questions, each with a detailed explanation shown after you answer.
Do I need to create an account to track my progress?
No account is required. Your progress bar and score reset each time you reload the page, but you can retry the exercise as many times as you like.
Who is this Streaming Data exercise for?
This exercise is built for IT professionals and non-native English speakers who need to read, write, and discuss streaming data topics confidently at work.
What happens if I answer a question incorrectly?
You will see the correct answer highlighted along with a detailed explanation of why it is correct -- so every wrong answer becomes a learning moment, not just a lost point.
Can I retry this exercise?
Yes -- click "Try again" on the results screen at any time to reset your score and go through all the questions again.
How long does this exercise take to complete?
Most learners finish all 10 questions in under 10 minutes, since each question is answered by clicking a single option.
Where can I find more Streaming Data exercises?
See the full Streaming Data exercises hub for more vocabulary drills on this topic.
Is this exercise mobile-friendly?
Yes -- the exercise works on any device with a modern browser, including phones and tablets, with no app download required.