reliable-messaginglisted

# Reliable Messaging Delivery is an application lifecycle, not a broker feature: `business state -> message identity -> durable publish -> broker acceptance -> consume -> durable effect -> acknowledge -> recover -> prove` State every guarantee with its start, durable commit, end, and accepted loss or duplicate window. Use “effectively once” only for a named business effect protected by durable idempotency. Reserve “exactly once” for a proven atomic boundary; broker deduplication alone is not an end-to-end guarantee. ## Choose the depth Follow only the path needed by the request: - **Review or diagnose:** reconstruct the affected boundary and its immediate dependencies, locate the earliest durable step that violates the claimed guarantee, and report the smallest correction and falsifier. Keep state unchanged. - **Design:** define each in-scope boundary, assumption, mechanism, and proof. Use a ledger when several boundaries interact; one row is enough for a narrow design. - **Build or fix:** patch the shared root cause locally and run the smallest test that fails on the old boundary and passes on the new one. - **Operate:** publishing, configuration changes, redrive, replay, purge, deletion, or credential rotation requires explicit authorization for the exact environment and bounds. Preflight, perform only the authorized action, and verify with fresh readback. Do not expand a narrow acknowledgement, identity, or routing issue into a full messaging redesign unless another