Estimate backlog drain time under explicit capacity assumptions

Project context

A fictional document service has a rising processing backlog. Operators cannot tell whether arrivals, worker failures, or a slow dependency is responsible.

Setup prerequisites

• Create a bounded local queue simulation with synthetic jobs and controllable worker/dependency failures.

Preceding work

Complete these dependencies, or supply their agreed outputs before taking this ticket.

• BINCIDENT-101 · Report oldest eligible job age alongside queue depth
• BINCIDENT-102 · Separate arrival rate from successful service rate
• BINCIDENT-103 · Identify poison jobs without starving unrelated work
• BINCIDENT-104 · Pause selected producers while preserving accepted work
• BINCIDENT-106 · Tune retry delay for a throttled dependency

Acceptance criteria

• Use measured successful service and arrival rates.
• Report assumptions and uncertainty bounds.
• Return no finite estimate when arrivals meet or exceed service.

Implementation constraints

• Use synthetic measurements and avoid general capacity claims.

Verification to include

• Estimate a controlled draining workload.
• Show an unstable workload as non-draining.

Deliverables

• Drain-time estimator.

Rollout and recovery

Publish estimates with their observation window; retract stale estimates.

Value of the work

For the engineer: Practice incident timelines, queue diagnosis, and measured recovery.

For the team: Produce a repeatable response that preserves work integrity and exposes customer delay.

Evidence boundaries

Outcome Evidence: Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs.

Ownership Evidence: Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence.