Compare rejection policies under the same offered workload
The team must choose between a larger queue and earlier rejection.
- Focused work estimate
- 5h + prerequisites
- Priority in the scenario
- High
- Engineering practice
- Performance analysis · Reliability tradeoffs
Estimated field mix
- Performance engineering60%
- Site reliability40%
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
Acceptance criteria
- Compare identical arrival traces and resource budgets.
- Measure essential latency, rejection, completion, and recovery separately.
- Explain tradeoffs and remaining uncertainty.
Implementation constraints
- Do not compare only successful-response latency or hide rejected work.
Verification to include
- Run both policies on the same synthetic burst.
- Expose a policy that improves accepted latency by rejecting more work.
Deliverables
- Admission policy assessment.
Rollout and recovery
Choose a bounded default and retain a tested configuration rollback.
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.