RabbitMQ — Lesson 3: Routing Patterns, Dead Letters, TTL, Retries, Confirms, and RPC

Learning Objectives

• Verify the roles, prerequisites, dependencies, and decision points that shape routing patterns, dead letters, ttl, retries, confirms, and rpc.
• Diagnose the workflow and produce routing-pattern test suite and controlled-retry evidence that another practitioner can review and repeat.
• Optimize “a retry queue returning poison messages indefinitely without a terminal dead-letter path” without introducing an unverified production change.

Detailed Topics

• direct exchanges
• topic exchanges
• fanout exchanges
• headers exchanges
• dead-letter exchanges
• message and queue TTL
• retry topologies
• publisher confirms
• transaction awareness
• request-reply and RPC
• Decision ownership and acceptance evidence for routing patterns, dead letters, ttl, retries, confirms, and rpc
• Relevant security, performance, resilience, rollback, and support considerations

Instructor Demonstration

The instructor demonstrates direct exchanges, topic exchanges, fanout exchanges, headers exchanges, dead-letter exchanges, message and queue TTL, retry topologies, publisher confirms, transaction awareness, request-reply and RPC in a representative environment. Each material checkpoint is captured in routing-pattern test suite and controlled-retry evidence, and the walkthrough contrasts the intended state with a condition where a retry queue returning poison messages indefinitely without a terminal dead-letter path.

Hands-On Exercise

Complete a controlled implementation or analysis for Routing Patterns, Dead Letters, TTL, Retries, Confirms, and RPC. Establish a known baseline, introduce or reproduce “a retry queue returning poison messages indefinitely without a terminal dead-letter path,” isolate the proven cause, apply a reversible correction, and record the accepted result in routing-pattern test suite and controlled-retry evidence.

1. Confirm scope, identities, infrastructure, dependencies, and expected result.
2. Execute the planned configuration or operational sequence while preserving checkpoints.
3. Test one expected path, one boundary condition, and the identified failure path.
4. Retest after correction and document rollback, ownership, and preventive action.

Scenario Analysis

• Decide which requirement or dependency has the greatest influence on routing patterns, dead letters, ttl, retries, confirms, and rpc.
• Compare two valid implementation or recovery choices and identify the evidence that would distinguish them.
• Explain how routing-pattern test suite and controlled-retry evidence should be reviewed, retained, and handed to the next owner.

Troubleshooting Guidance

Begin with effective configuration, recent changes, connectivity, health, logs, and timing. Use routing-pattern test suite and controlled-retry evidence to find the earliest divergence between expected and observed behavior. Treat “a retry queue returning poison messages indefinitely without a terminal dead-letter path” as a hypothesis until the corrected path passes both the original test and a boundary condition.

Validation Checklist

• The implemented state for routing patterns, dead letters, ttl, retries, confirms, and rpc is traceable to approved inputs.
• Routing-pattern test suite and controlled-retry evidence contains baseline, test, correction, and accepted-result evidence.
• Security, capacity, performance, resilience, downstream impact, and rollback were considered where relevant.
• Monitoring, escalation, recovery, and support ownership are clear enough for operational use.

Lesson Outcome

Learners can apply Routing Patterns, Dead Letters, TTL, Retries, Confirms, and RPC, explain the decisions made, and defend the result with routing-pattern test suite and controlled-retry evidence.