Prevent capacity oscillation when the burst ends
Degradation switches on and off rapidly near the threshold.
- Focused work estimate
- 3h + prerequisites
- Priority in the scenario
- High
- Engineering practice
- Control systems
Estimated field mix
- Site reliability60%
- Platform engineering40%
Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.
Review it, then add it to your workspace.
The board opens an editable draft; nothing is saved until you confirm it. Sign-in and workspace permissions apply, and Demo boards remain ephemeral.
Project context
A fictional ticketing service becomes unresponsive during event releases because optional recommendation calls consume the same resources as reservation checks.
Setup prerequisites
- Build a bounded local service and synthetic open-loop workload generator with controllable dependency delays.
Preceding work
Complete these dependencies, or supply their agreed outputs before taking this ticket.
- BLOADSHED-101 · Classify essential and optional ticketing requests
- BLOADSHED-102 · Build a workload that preserves offered arrival rate
- BLOADSHED-103 · Bound the waiting queue before worker slots are exhausted
- BLOADSHED-104 · Isolate optional recommendation concurrency
- BLOADSHED-105 · Propagate request deadlines to downstream work
- BLOADSHED-106 · Provide retry guidance that does not synchronize every client
- BLOADSHED-107 · Preserve fair access across tenant request queues
- BLOADSHED-108 · Compare rejection policies under the same offered workload
Acceptance criteria
- Add declared hysteresis or cooldown semantics.
- Return to normal after sustained recovery.
- Keep manual emergency controls auditable.
Implementation constraints
- Avoid permanent degradation after transient overload.
Verification to include
- Recover after a controlled burst.
- Oscillate near thresholds and verify bounded mode changes.
Deliverables
- Recovery controller tests.
Rollout and recovery
Run in observation mode first; allow a safe fixed-policy fallback.
Value of the work
For the engineer: Practice overload behavior, admission control, and fair performance experiments.
For the team: Create predictable failure and degradation behavior under declared capacity constraints.
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.