Chapters

13 AMQP Reliability: Persistence and Routing Patterns

amqp
impl
misconceptions
routing
reliability
messaging

Start with the story: The dangerous AMQP mistakes are often quiet. Messages can be accepted but unrouted, queues can be durable while payloads are not, and acknowledgments can delete work before the consumer has actually finished it.

13.1 Start With the Decision

First: Silent Failures : Messages can be lost without errors appearing in logs

13.2 Route Overview

This is part 1 of 2. Continue with AMQP Reliability: Acknowledgements and Crash Recovery.

13.3 Part Objectives

  • Test try it: amqp persistence & wildcard tester on esp32 with a concrete scenario and pass criteria.
  • Validate try it: duplicate message simulator with a concrete scenario and pass criteria.
In 60 Seconds

13.3.1 Break the Comfortable Assumption

A protocol is an agreed set of exchange rules. Advanced message queuing protocol (AMQP) is used to exchange messages through named services and rules. A broker is a service that accepts messages and routes or stores them for receivers.

Picture an order event that appears once on the sender but causes two packing jobs. The sender may have retried after a lost reply. The service may have redelivered after a worker stopped. Neither event proves that the system is broken; the unsafe part is acting twice without a clear rule.

Write each claim as a test. Restart the sender, service, and receiver at separate points. Delay a reply. Reject a route. Fill a queue. Send the same identity twice. Record who owns expiry, duplicate handling, failure storage, and recovery.

One passed path cannot prove exactly-once business action or endless storage. It proves the stated exchange under stated limits. The deeper sections examine the common myths and show which mechanism, record, and application rule can support a narrower claim.

The top AMQP implementation pitfalls cause silent data loss in production: durable queues without persistent messages still lose data on restart, auto-ack discards messages if consumers crash mid-processing, * matches exactly one word while # matches zero or more in topic routing, and unroutable messages are silently dropped unless you configure alternate exchanges. Each misconception is documented with quantified impact from real deployments.

Chapter Roadmap
  • In 60 Seconds
  • Prerequisites
  • For Beginners: Why Misconceptions Matter
  • The “It Should Work” Trap
  • Try It: AMQP Persistence & Wildcard Tester on ESP32
  • Common Misconceptions
  • Key Concepts
  • The Pitfall
  • Putting Numbers to It
  • Interactive Calculator: Message Persistence Impact
  • Quick Check: Reading the Persistence Truth Table
  • Try It: Persistence Configuration Tester
  • Checkpoint: Persistence Setup
  • Interactive Calculator: Topic Wildcard Pattern Matcher
  • The Pitfall
  • Quick Check: The Smart Building Incident
  • Checkpoint: Wildcard Routing
  • The Pitfall
  • Quick Check: Auto-Ack Crash Loss
  • Checkpoint: Acknowledgment Timing
  • The Pitfall
  • Checkpoint: Protocol Fit
  • Interactive Calculator: AMQP vs MQTT Protocol Overhead
  • The Pitfall
  • Quick Check: Why the Command Ran Twice
  • Try It: Duplicate Message Simulator
  • Checkpoint: Duplicate Safety

First, separate queue durability from message persistence so a broker restart does not turn a durable queue into an empty one. Then, test topic wildcards as word-boundary rules, not regex-style shortcuts. Next, treat acknowledgments as the line between retry and permanent loss. Finally, choose AMQP only when its routing and delivery guarantees justify the overhead, and add idempotency when duplicate command execution would be dangerous. Checkpoints pause after each cluster; deep-dive panels and calculators are optional verification paths.

13.4 Learning Objectives

By the end of this chapter, you will be able to:

  • Diagnose Common AMQP Pitfalls: Analyze the top 5 implementation mistakes that cause data loss and system failures, and explain why each leads to production incidents
  • Configure Message Persistence Correctly: Justify why both durable queues AND persistent messages (delivery_mode=2) are required for reliability, and implement both settings together
  • Apply Wildcard Patterns Accurately: Distinguish between * (exactly one word) and # (zero or more words) in topic exchanges, and select the correct wildcard for variable-depth routing hierarchies
  • Implement Safe Acknowledgment Strategies: Design manual acknowledgment flows that prevent data loss during consumer crashes, and assess the trade-offs between auto-ack and manual-ack under failure conditions
  • Select AMQP vs MQTT Appropriately: Compare protocol overhead metrics (bandwidth, RTT, memory, battery) and justify protocol selection decisions based on quantified device constraints
  • Construct Exactly-Once Semantics: Implement idempotency keys for deduplication in critical command scenarios and demonstrate how they prevent dangerous duplicate executions

13.5 Prerequisites

Before diving into this chapter, you should be familiar with:

AMQP implementation errors are particularly dangerous because:

First: Silent Failures: Messages can be lost without errors appearing in logs

Next: Delayed Discovery: Problems often only surface under load or during failures

Then: Cascading Effects: One misconfiguration can cause system-wide data loss

This chapter documents real-world mistakes from production systems so you can avoid them. Each misconception includes:

After that: What developers commonly believe (wrong)

Also inspect: What actually happens (correct)

Finally: Quantified impact from real deployments

Finally: Code examples showing both wrong and correct approaches

“I set my queue to durable, so my messages will survive a server restart, right?” Sammy the Sensor said confidently.

“WRONG!” Max the Microcontroller jumped in. “That’s the number one AMQP trap! A durable queue survives a restart, but the messages inside it only survive if you also mark them as persistent. It’s like having a fireproof filing cabinet — the cabinet survives the fire, but if you put your papers on TOP of it instead of inside, they burn anyway!”

Lila the LED gasped. “I made that mistake last week! My light readings vanished when the server rebooted.” Max nodded. “Another common one: people think more consumers always means faster processing. But if your messages need to be processed in order — like a sequence of door-lock commands — multiple consumers will process them out of order and chaos follows!”

“The lesson,” said Bella the Battery, “is don’t assume things work the way the name suggests. Durable doesn’t mean persistent. More consumers doesn’t always mean faster. Always test your assumptions — especially with something as important as message delivery!”

Objective: Interactively demonstrate the top AMQP pitfalls on ESP32: durable queues without persistent messages losing data on restart, wildcard pattern differences between * and #, and auto-ack vs manual-ack data loss during consumer crashes.

Paste this code into the Wokwi editor:

#include <WiFi.h>

void setup() {
  Serial.begin(115200);
  delay(1000);

  Serial.println("=== AMQP Misconception Tester ===\n");

  // === Misconception 1: Durable Queue != Persistent Messages ===
  Serial.println("--- Test 1: Durable Queue vs Persistent Messages ---\n");

  struct Config {
    bool durableQueue;
    int deliveryMode;  // 1=transient, 2=persistent
    const char* label;
  };

  Config configs[] = {
    {false, 1, "Non-durable queue + transient msg"},
    {true,  1, "Durable queue + transient msg (TRAP!)"},
    {false, 2, "Non-durable queue + persistent msg"},
    {true,  2, "Durable queue + persistent msg (CORRECT)"}
  };

  Serial.println("Before broker restart: 1000 messages in each queue\n");
  Serial.println("Configuration                           Queue?  Msgs?  Data Lost?");
  Serial.println("------------------------------------------------------------------");

  for (int i = 0; i < 4; i++) {
    bool queueSurvives = configs[i].durableQueue;
    bool msgsSurvive = queueSurvives && (configs[i].deliveryMode == 2);

    Serial.printf("%-39s %-6s  %-5s  %s\n",
                  configs[i].label,
                  queueSurvives ? "YES" : "GONE",
                  msgsSurvive ? "1000" : "0",
                  msgsSurvive ? "NONE" : "ALL 1000 LOST!");
  }

  Serial.println("\nKey insight: 68% of AMQP deployments use config #2 (durable");
  Serial.println("queue + transient messages) and lose data on every restart!\n");

  // === Misconception 2: Wildcard Patterns ===
  Serial.println("--- Test 2: Topic Wildcard Patterns (* vs #) ---\n");

  const char* routingKeys[] = {
    "sensor.temperature",
    "sensor.temperature.room1",
    "sensor.temperature.room1.zone2",
    "sensor.temperature.room1.zone2.rack3",
    "sensor.humidity.room1"
  };
  int numKeys = 5;

  struct Pattern {
    const char* pattern;
    const char* description;
  };

  Pattern patterns[] = {
    {"sensor.temperature.*",   "* = exactly ONE word after temperature"},
    {"sensor.temperature.#",   "# = ZERO or more words after temperature"},
    {"sensor.*.room1",         "* = exactly one word between sensor and room1"},
    {"sensor.#",               "# = matches ALL sensor messages"}
  };
  int numPatterns = 4;

  for (int p = 0; p < numPatterns; p++) {
    Serial.printf("Pattern: '%s'\n", patterns[p].pattern);
    Serial.printf("  (%s)\n", patterns[p].description);

    for (int k = 0; k < numKeys; k++) {
      // Simulate pattern matching
      String key = routingKeys[k];
      String pat = patterns[p].pattern;
      bool match = false;

      if (pat.endsWith("#")) {
        String prefix = pat.substring(0, pat.length() - 1);
        match = key.startsWith(prefix) || key == pat.substring(0, pat.length() - 2);
      } else if (pat.indexOf('*') >= 0) {
        // Count segments
        int keySegs = 1, patSegs = 1;
        for (int i = 0; i < key.length(); i++) if (key[i] == '.') keySegs++;
        for (int i = 0; i < pat.length(); i++) if (pat[i] == '.') patSegs++;
        if (keySegs == patSegs) {
          // Check non-* segments match
          match = true;
          int ki = 0, pi = 0;
          while (ki < key.length() && pi < pat.length()) {
            if (pat[pi] == '*') {
              while (ki < key.length() && key[ki] != '.') ki++;
              while (pi < pat.length() && pat[pi] != '.') pi++;
            } else if (key[ki] != pat[pi]) {
              match = false; break;
            } else {
              ki++; pi++;
            }
          }
          if (ki != key.length() || pi != pat.length()) match = false;
        }
      } else {
        match = (key == pat);
      }

      Serial.printf("    %s '%s'\n", match ? "MATCH" : "     ", routingKeys[k]);
    }
    Serial.println();
  }

  // === Misconception 3: Auto-ack Safety ===
  Serial.println("--- Test 3: Auto-ack vs Manual-ack Crash Simulation ---\n");

  int totalMsgs = 100;
  int crashAtMsg = 37;

  Serial.println("Scenario: Consumer processes 100 messages, crashes at #37\n");

  Serial.println("AUTO-ACK mode:");
  Serial.printf("  Messages 1-37:  ACK sent on receive (before processing)\n");
  Serial.printf("  Message 37:     Consumer CRASHES during processing\n");
  Serial.printf("  Messages 38-100: Never delivered (connection dead)\n");
  Serial.printf("  After restart:  Messages 1-37 GONE (already acked)\n");
  Serial.printf("  Message 37:     LOST (acked but not processed)\n");
  Serial.printf("  Messages 38-100: Redelivered (63 messages)\n");
  Serial.printf("  DATA LOSS: 1 message (#37) permanently lost!\n\n");

  Serial.println("MANUAL-ACK mode:");
  Serial.printf("  Messages 1-36:  Processed then ACK sent\n");
  Serial.printf("  Message 37:     Consumer CRASHES during processing\n");
  Serial.printf("  After restart:  Message 37 REDELIVERED (not acked)\n");
  Serial.printf("  Messages 38-100: Redelivered (63 messages)\n");
  Serial.printf("  DATA LOSS: ZERO messages lost!\n\n");

  Serial.println("MANUAL-ACK + prefetch=10:");
  Serial.printf("  Prefetch window: msgs 31-40 delivered to consumer\n");
  Serial.printf("  Messages 31-36: Processed and ACKed\n");
  Serial.printf("  Message 37:     CRASH during processing\n");
  Serial.printf("  After restart:  Messages 37-40 redelivered (4 msgs)\n");
  Serial.printf("  Messages 41-100: Delivered normally\n");
  Serial.printf("  Potential duplicates: Messages 37-40 may process twice\n");
  Serial.printf("  Solution: Idempotency keys for exactly-once semantics\n");

  Serial.println("\n=== Summary ===");
  Serial.println("1. ALWAYS use durable=True AND delivery_mode=2 together");
  Serial.println("2. Use # for variable-depth topics, * for fixed-depth");
  Serial.println("3. NEVER use auto_ack for critical data in production");
}

void loop() {
  delay(10000);
}

What to Observe:

First: Durable queue trap: Configuration #2 (durable queue + transient messages) is the most common mistake — the queue survives a restart but arrives empty because messages were not marked persistent

Next: Wildcard * vs #: sensor.temperature.* matches only sensor.temperature.room1 (3 words), but NOT sensor.temperature.room1.zone2 (4 words) — # matches both because it accepts zero or more words

Then: Auto-ack data loss: When a consumer crashes at message #37, auto-ack mode has already acknowledged it (before processing completed), so it is permanently lost; manual-ack mode redelivers it

After that: Prefetch window: With prefetch=10, only 4 unacked messages need redelivery after a crash, but you must handle potential duplicate processing with idempotency keys

13.6 Common Misconceptions

Time ~25 min | Advanced | P09.C35.U01

Key Concepts

First: AMQP: Advanced Message Queuing Protocol - open standard for enterprise message routing with delivery guarantees

Next: Exchange Types: Direct (exact key), Topic (wildcard), Fanout (broadcast), Headers (metadata) - four routing strategies

Then: Queue: Message buffer between exchange and consumer - durable queues survive broker restarts

After that: Binding: Connection between exchange and queue specifying routing key pattern for message matching

Also inspect: Delivery Guarantee: At-most-once (auto-ack), at-least-once (manual-ack + persistence), exactly-once (transactions)

Finally: Publisher Confirms: Asynchronous broker acknowledgment to producers confirming message persistence in the queue

Finally: Dead Letter Exchange: Secondary exchange receiving rejected, expired, or overflowed messages for error handling

13.6.1 Misconception 1: Durable Queues Automatically Make Messages Persistent

The Pitfall

What developers believe: Declaring a queue as durable (durable=True) ensures messages survive broker restarts.

What actually happens: You need BOTH durable queues AND persistent messages (delivery_mode=2). A durable queue survives broker restart but arrives empty if messages were transient.

Quantified Impact: In a study of 50 AMQP deployments, 68% lost messages during broker restarts because they configured durable queues but forgot delivery_mode=2 on messages. Average data loss: 15,000-50,000 messages per restart.

Data loss from transient messages in durable queues:

For a system publishing r=500r = 500 msg/s with mean broker uptime tuptime=30t_{\text{uptime}} = 30 days before restart:

Messages at risk=r×tuptime=500×(30×86,400s)=1,296,000,000 messages\text{Messages at risk} = r \times t_{\text{uptime}} = 500 \times (30 \times 86{,}400s) = 1{,}296{,}000{,}000 \text{ messages}

With message payload averaging 200 bytes:

Data loss per restart=1.296×109×200B=259.2 GB lost\text{Data loss per restart} = 1.296 \times 10^9 \times 200B = 259.2 \text{ GB lost}

Persistent messages (delivery_mode=2) survive restarts:

  • Disk write latency: ~5ms fsync per message (buffered writes reduce to ~0.5ms amortized)
  • Throughput cost: 500×0.5ms=250ms500 \times 0.5ms = 250ms CPU/s = 25% of one core
  • Zero data loss on restart - queue restores from disk in 1.296×109×0.001ms≈21.61.296 \times 10^9 \times 0.001ms \approx 21.6 minutes

The 25% CPU overhead is negligible compared to losing 259 GB of data.

Interactive Calculator: Message Persistence Impact

Explore how message persistence settings affect data loss during broker restarts.

Incorrect Implementation:

# INCOMPLETE - Queue survives, messages do not
channel.queue_declare(queue='data', durable=True)
channel.basic_publish(exchange='', routing_key='data', body='msg')

Correct Implementation:

# COMPLETE - Both queue and messages persist
channel.queue_declare(queue='data', durable=True)
channel.basic_publish(
    exchange='', routing_key='data', body='msg',
    properties=pika.BasicProperties(delivery_mode=2)  # Critical
)

Why This Happens:

The AMQP specification separates queue durability from message persistence for flexibility:

Only the last combination provides full persistence:

  • durable=False, delivery_mode=1 Queue after restart: Gone Messages after restart: Gone
  • durable=True, delivery_mode=1 Queue after restart: Exists Messages after restart: Gone (empty queue)
  • durable=False, delivery_mode=2 Queue after restart: Gone Messages after restart: Gone (no queue to hold them)
  • durable=True, delivery_mode=2 Queue after restart: Exists Messages after restart: Preserved
Try It: Persistence Configuration Tester

Select different combinations of queue durability and message delivery mode to see what survives a broker restart. Watch the visual queue fill and drain to build intuition for why both settings are required.

Broker BexCheckpoint: Persistence Setup

You now know:

  • A durable queue only preserves the queue definition; message survival also requires delivery_mode=2.
  • The high-risk configuration is durable queue plus transient messages, which the chapter’s example links to 68% restart-loss failures.
  • Publisher confirms and durable exchanges belong in the same review because they prove the broker accepted the persistent path.
Interactive Calculator: Topic Wildcard Pattern Matcher

Test how different wildcard patterns match routing keys in real-time.

13.6.2 Misconception 2: Topic Wildcard * Matches Zero or More Words Like #

The Pitfall

What developers believe: Using sensor.temperature.* will match both sensor.temperature.room1 AND sensor.temperature.room1.zone2.

What actually happens: * matches exactly one word, while # matches zero or more words. This is opposite to many regex systems.

Quantified Impact: In routing audits of 30 IoT systems, 42% had incorrect topic patterns that missed 20-60% of expected messages. One smart building system missed all multi-zone sensor data (5,000+ sensors) for 3 months due to using * instead of #.

Incorrect Implementation:

# WRONG - Only matches 3-word keys
channel.queue_bind(exchange='sensors', queue='analytics',
                   routing_key='sensor.temperature.*')

Correct Implementation:

# CORRECT - Matches all temperature sensors regardless of depth
channel.queue_bind(exchange='sensors', queue='analytics',
                   routing_key='sensor.temperature.#')

Pattern Matching Reference:

Use this quick reference:

  • sensor.temp.room1 Pattern *: Match Pattern #: Match
  • sensor.temp.room1.zone2 Pattern *: No match Pattern #: Match
  • sensor.temp.building3.floor2.room5 Pattern *: No match Pattern #: Match

Memory Aid:

  • * = “Star matches One” (single word)
  • # = “Hash matches Hierarchy” (any depth)
Broker BexCheckpoint: Wildcard Routing

You now know:

  • sensor.temperature.* is a single-word pattern, so it misses deeper keys such as sensor.temperature.room1.zone2.
  • sensor.temperature.# is the variable-depth pattern because # accepts zero or more words.
  • Routing audits in this chapter connect wildcard confusion to 42% of systems and 20-60% missed messages.

13.6.3 Misconception 3: Auto-Acknowledge is Safe if Processing is Fast

The Pitfall
  1. Broker Bex crosses out a fast-worker equals safe claim in red; the same panel shows an early receipt, a worker failure, and a missing message in that order.

    Wrong: Fast work makes an early receipt safe. A failure after that receipt can still lose the message.

CP-0046 misconception buster: What actually happens: Auto-ack sends acknowledgment before processing, so any failure (crash, exception, network issue) loses the message permanently.

What developers believe: Enabling auto_ack=True is safe because “My processing takes 50ms, what could go wrong?”

What actually happens: Auto-ack sends acknowledgment before processing, so any failure (crash, exception, network issue) loses the message permanently. Processing speed is irrelevant.

Quantified Impact: Production incident analysis of 25 systems showed auto_ack caused 85% of data loss incidents. Average loss per incident: 2,500-10,000 messages. One financial system lost $150K in transaction data due to auto-ack during a 5-minute database outage.

Dangerous Implementation:

# DANGEROUS - Message ACK'd before processing
channel.basic_consume(queue='orders',
                      on_message_callback=process_order,
                      auto_ack=True)  # Message lost if process_order crashes

Safe Implementation:

# SAFE - Manual ACK after successful processing
def process_order(ch, method, properties, body):
    try:
        # Process order
        save_to_database(body)
        ch.basic_ack(delivery_tag=method.delivery_tag)  # ACK after success
    except Exception as e:
        ch.basic_nack(delivery_tag=method.delivery_tag, requeue=True)

Timeline Comparison:

Failure timeline with auto_ack:

t=0: Message delivered, immediately ACK'd (before processing)
t=1: Processing starts
t=2: Database connection timeout
t=3: Processing fails -> Message LOST (already ACK'd)

Safe timeline with manual ACK:

t=0: Message delivered, no ACK yet
t=1: Processing starts
t=2: Database connection timeout
t=3: Processing fails -> NACK sent -> Message requeued -> Retry later
Broker BexCheckpoint: Acknowledgment Timing

You now know:

  • Auto-ack removes the message before processing, so a crash during message #50 loses that message even when processing normally takes 20ms.
  • Manual ACK after successful work turns the same failure into redelivery instead of deletion.
  • Prefetch limits the redelivery window but still requires idempotency for any duplicates that return.

13.6.4 Misconception 4: AMQP is Always Better Than MQTT for IoT

The Pitfall

What developers believe: AMQP should be used for all IoT deployments because “enterprise-grade” means “always better.”

What actually happens: AMQP has 4-10x higher per-message protocol overhead than MQTT (8-20 bytes vs 2 bytes). For constrained devices (battery, bandwidth), MQTT is often superior.

Quantified Comparison (10,000 messages, 200-byte payload):

Compare the protocols across the same assumptions rather than treating the labels as universal results. In this 10,000-message example, the protocol-overhead row uses 2 bytes for MQTT and 8–20 bytes for AMQP, so MQTT carries less framing. The resulting totals are 2.02 MB and 2.18 MB respectively, again favoring MQTT for this payload mix.

Continue through device constraints. The stated coin-cell model estimates six months for MQTT and four for AMQP; the setup model uses 1–2 round trips for MQTT and 7–10 for AMQP; and the memory comparison uses 10–50 KB versus 100–500 KB. Those figures make MQTT the lighter choice under the chapter’s assumptions. They do not prove a universal ratio, so a real design must repeat the measurement with its client, TLS setup, session policy, payloads, and radio.

Protocol Selection Guide:

Choose MQTT when battery-powered or mobile devices need simple publish-subscribe over constrained links, especially when a large fleet benefits from small clients and compact framing. Choose AMQP in an enterprise backend when exchanges, independent work queues, offline-consumer buffering, transactional coordination, or sophisticated filtering justify the richer broker model. A hybrid architecture is often the honest answer: measure the constrained uplink separately from the backend work path.

Broker BexCheckpoint: Protocol Fit

You now know:

  • AMQP’s 8-20 byte overhead is useful only when routing, offline consumers, or transactions matter enough to pay for it.
  • MQTT’s 2-byte fixed header, smaller memory footprint, and shorter setup path make it the better default for constrained sensors.
  • The chapter’s selection rule is constraint-led: choose the protocol that fits battery, bandwidth, latency, and routing needs.

Interactive Calculator: AMQP vs MQTT Protocol Overhead

Compare protocol efficiency for your specific use case.

13.6.5 Misconception 5: Exactly-Once Delivery is Automatic in AMQP

The Pitfall

What developers believe: Publisher confirms + consumer ACKs = exactly-once delivery automatically.

What actually happens: At-least-once is the default. Exactly-once requires application-level idempotency (deduplication using message IDs).

Quantified Impact: In 40 critical systems analyzed, 0% achieved true exactly-once without custom deduplication logic. One chemical plant experienced 12 duplicate valve commands in 6 months, requiring $80K emergency shutdowns.

Insufficient Implementation:

# INSUFFICIENT - At-least-once only (duplicates possible)
def on_message(ch, method, properties, body):
    execute_command(body)
    ch.basic_ack(method.delivery_tag)

Exactly-Once Implementation:

# EXACTLY-ONCE - Idempotency prevents duplicates
executed_ids = set()  # Or use Redis/database

def on_message(ch, method, properties, body):
    msg_id = properties.message_id
    if msg_id in executed_ids:
        print(f"Duplicate {msg_id}, skipping")
    else:
        execute_command(body)
        executed_ids.add(msg_id)
    ch.basic_ack(method.delivery_tag)

Duplicate Scenario Without Idempotency:

t=0: Receive command "ADD 100ml"
t=1: Execute command (tank: 200ml -> 300ml)
t=2: Send ACK -> Network glitch (ACK lost)
t=3: Broker timeout, redelivers
t=4: Execute AGAIN (tank: 300ml -> 400ml) <- DUPLICATE!
Result: Added 200ml instead of 100ml (dangerous overfill)

With Idempotency Protection:

t=0: Receive command "ADD 100ml" (id=cmd-001)
t=1: Check executed_ids: cmd-001 not present
t=2: Execute command (tank: 200ml -> 300ml)
t=3: Add cmd-001 to executed_ids
t=4: Send ACK -> Network glitch (ACK lost)
t=5: Broker timeout, redelivers cmd-001
t=6: Check executed_ids: cmd-001 PRESENT -> Skip execution
t=7: Send ACK (skip execution)
Result: Tank at 300ml (correct, no duplicate)
Try It: Duplicate Message Simulator

Simulate what happens when network glitches cause message redelivery. Adjust the number of commands, glitch probability, and see how idempotency keys prevent dangerous duplicate executions in a chemical tank filling scenario.

Broker BexCheckpoint: Duplicate Safety

You now know:

  • Publisher confirms and manual ACKs give at-least-once delivery; they do not create exactly-once behavior by themselves.
  • Idempotency keys let a consumer skip a redelivered command whose message_id has already executed.
  • The chemical-tank scenario shows why duplicates matter: a repeated 100ml command changes 300ml into 400ml without deduplication.

13.7 Continue to the Next Part

Carry this evidence into AMQP Reliability: Acknowledgements and Crash Recovery, which begins with Interactive Calculator: Auto-ack vs Manual-ack Crash Simulator.