Building on Part 1's foundation, this guide extends the Go, PostgreSQL, and RabbitMQ transactional outbox with failure-aware behavior. It introduces producer-side retries using exponential backoff, dead-letter queues (DLQs) for permanently failed events, and consumer-side retries via RabbitMQ's dead-letter exchanges. The goal is to make the system resilient and boring to operate.

The core challenge is handling transient failures without amplifying problems. The article details schema changes for tracking retry_count and next_retry_at, ensuring state is durable. For consumers, it classifies errors as permanent or transient, routing only the latter to retry exchanges. This prevents infinite loops and isolates poison messages.

Observability is key, with dedicated metrics for retry attempts and DLQ publishing, plus tracing attributes for outcome visibility. The piece also compares polling-based versus CDC-based outbox implementations (using Debezium and Kafka), weighing operational complexity against latency benefits. The final system is designed for debuggability and graceful degradation.