🎯 Core Delivery Semantics Framework
When discussing delivery semantics, I frame it as:
- What delivery guarantees actually mean
- At-least-once vs Exactly-once trade-offs
- Failure scenarios and correctness implications
- Real-world implementation patterns
1️⃣ Delivery Semantics Basics
Definitions
- At-least-once → message may be delivered multiple times
- Exactly-once → message is processed once (no duplicates, no loss)
Key Insight
Exactly-once is not a transport property — it’s an end-to-end system guarantee
👉 Interview Answer
Delivery guarantees define how messages are delivered and processed. At-least-once allows duplicates but avoids message loss, while exactly-once ensures each message is processed once. In practice, exactly-once is not just about the messaging system, but requires end-to-end coordination across producers, brokers, and consumers.
2️⃣ At-least-once vs Exactly-once
At-least-once Delivery
Strengths:
- Simple to implement
- High availability
- No data loss (with retries)
Limitations:
- Duplicate messages
- Requires idempotent consumers
👉 Interview Answer
At-least-once delivery ensures messages are not lost, but they may be delivered multiple times. I typically use this model with idempotent consumers, so duplicate processing does not affect correctness.
Exactly-once Delivery
Strengths:
- No duplicates
- Strong correctness guarantees
Limitations:
- High complexity
- Performance overhead
- Requires coordination
👉 Interview Answer
Exactly-once delivery guarantees that each message is processed only once. However, achieving this requires coordination across components, such as transactional writes and deduplication, which increases complexity and latency.
Summary
| Aspect | At-least-once | Exactly-once |
|---|---|---|
| Data loss | No | No |
| Duplicates | Yes | No |
| Complexity | Low | High |
| Performance | High | Lower |
👉 Interview Answer（总结一句）
At-least-once is simple and scalable but requires handling duplicates, while exactly-once provides stronger guarantees at the cost of complexity and performance.
3️⃣ Failure Scenarios (Staff-Level Core)
Scenario 1: Consumer crashes after processing
- Message processed but not acknowledged
👉 Interview Answer
If a consumer processes a message but crashes before acknowledging it, the system will retry the message, leading to duplicate processing in at-least-once systems.
Scenario 2: Message acknowledged before processing
- Risk of message loss
👉 Interview Answer
If a message is acknowledged before processing completes, a failure may result in message loss. This is why acknowledgments should only happen after successful processing.
Scenario 3: Network failure during commit
👉 Interview Answer
Network failures during commit can lead to uncertainty about whether a message was processed. This is one of the key challenges in achieving exactly-once semantics.
Failure Insight
The system must handle duplicates OR loss OR coordination complexity
👉 Interview Answer（总结一句）
In distributed systems, we typically choose between handling duplicates, risking data loss, or adding coordination complexity to avoid both.
4️⃣ Real-world Implementation Patterns
Pattern 1: Idempotent Consumer (Most Common)
👉 Interview Answer
The most common approach is to use at-least-once delivery with idempotent consumers, where processing the same message multiple times produces the same result.
Pattern 2: Deduplication
- Store processed message IDs
👉 Interview Answer
I often use deduplication by storing message IDs, so the system can detect and ignore duplicate messages.
Pattern 3: Transactional Processing
- Message + DB write in one transaction
👉 Interview Answer
For exactly-once semantics, I use transactional processing where message consumption and state updates are committed atomically, ensuring consistency.
Pattern 4: Kafka Exactly-once Semantics
- Producer idempotency + transactional writes
👉 Interview Answer
Systems like Apache Kafka provide exactly-once semantics by combining idempotent producers and transactional consumers, but this still requires careful end-to-end design.
Pattern 5: Outbox Pattern
👉 Interview Answer
I use the outbox pattern to ensure consistency between database writes and message publishing, avoiding dual-write problems in distributed systems.
🧠 Staff-Level Answer (Final Polished)
👉 Interview Answer（完整背诵版）
When discussing delivery semantics, I focus on the trade-off between simplicity and correctness. At-least-once delivery is simple and reliable, but requires handling duplicate messages. Exactly-once delivery provides stronger guarantees, but requires coordination and increases complexity.
In practice, I usually prefer at-least-once delivery with idempotent consumers, because it scales better and is easier to operate.
For systems requiring stronger guarantees, I use patterns like transactional processing or deduplication, but I’m mindful of the performance and operational overhead.
⭐ Staff-Level Insight（拉开差距）
👉 Interview Answer
Exactly-once is not about eliminating duplicates — it’s about ensuring duplicates do not affect correctness.
中文速背版（Staff级）
At-least-once
不丢数据 → 但会重复
Exactly-once
不重复 → 但复杂 + 成本高
核心
三选二：不丢 + 不重复 + 简单
实战
大多数系统：at-least-once + 幂等
一句话总结
exactly-once 是“系统保证”，不是 MQ 自带能力
下一步
👉 “Message Queue 全家桶（ordering / partition / Kafka vs SQS / stream processing）”
Implement