Reliability and Delivery Semantics

Reliability in event-driven systems is not a property you buy from the broker and then stop thinking about. Delivery labels, retry strategy, dead-letter handling, and failure isolation all shape whether the platform degrades safely or turns small faults into duplicated business effects and stuck work.

Read the lessons in order. The first separates transport guarantees from application-level correctness. The second focuses on retry policy, including backoff and jitter. The third explains dead-letter queues and poison-message handling. The fourth turns to failure isolation and partial success, which is where many production incidents become harder than the happy path suggests.

If a team can describe how events flow when everything works but cannot explain what happens under duplicate delivery, repeated failure, or mixed per-record outcomes, Chapter 7 is where that reliability model needs to become explicit.

In this section

• At-Most-Once, At-Least-Once, and Effectively-Once
  A practical lesson on delivery semantics, duplicate risk, and why effectively-once behavior is usually an application design goal rather than a broker promise.
• Retries, Backoff, and Jitter
  A practical lesson on retry policy design, including transient versus permanent failure, exponential backoff, and jitter to reduce retry storms.
• Dead-Letter Queues and Poison Messages
  A practical lesson on dead-letter handling, poison-message diagnosis, and why dead-letter queues should be treated as operational control points rather than silent discard bins.
• Failure Isolation and Partial Success
  A practical lesson on isolating event-handling faults, limiting blast radius, and designing for cases where some work succeeds while other work must retry or escalate.