Readiness should see the recovery queue

What the public implementation shows

The readiness endpoint checks database connectivity, pending outbox backlog, and dead-letter callback count against configurable thresholds.

Liveness remains a process signal while readiness incorporates dependencies and accumulated recovery work. This is the implementation fact behind the note; the architectural reading begins from that visible boundary rather than from an assumed production story.

Operating principleA process can be alive while its promise to deliver events is operationally broken.

The decision behind the mechanism

Queue health is treated as service capability, not merely as a dashboard metric.

A gateway can continue accepting payments while callback obligations accumulate beyond the team’s ability to recover. The mechanism matters because it gives that failure a named boundary, durable evidence, and a controlled response instead of leaving the outcome to timing or operator guesswork.

• Keep liveness independent from downstream queues.
• Set explicit pending and dead-letter thresholds.
• Expose counts in operations dashboards and metrics.
• Document how readiness recovers after backlog reduction.

How the control should be operated

Thresholds need capacity evidence, alert ownership, drain procedures, and a distinction between transient spikes and sustained failure.

Traffic management can respond before recovery debt becomes invisible institutional debt. The reusable lesson is not to copy a class or endpoint in isolation, but to preserve the relationship between identity, state, authority, evidence, and operational ownership.