Isolate optional recommendation concurrency
Slow recommendations consume every outbound connection.
- Focused work estimate
- 3h + prerequisites
- Priority in the scenario
- High
- Engineering practice
- Bulkheads · Concurrency
Estimated field mix
- Site reliability40%
- Performance engineering30%
- Networking30%
Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.
Pattern topics
- BulkheadApply
Bound optional recommendation concurrency separately from essential requests and show that exhausted optional capacity cannot consume the essential reserve.
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.
Acceptance criteria
- Use a separate optional-work concurrency budget.
- Reserve declared capacity for essential requests.
- Skip optional work when its budget is unavailable.
Implementation constraints
- Use a real bounded pool, not an unbounded background task list.
Verification to include
- Serve reservations while recommendations stall.
- Exhaust optional slots and verify graceful omission.
Deliverables
- Optional-work bulkhead.
Rollout and recovery
Enable the bulkhead before increasing overall concurrency.
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.