Gate quote changes on repeated tail-latency and correctness checks
The team can demonstrate one fast run, but it has no rule for accepting noisy results or reverting a change that prices correctly only at low concurrency.
- Focused work estimate
- 5h + prerequisites
- Priority in the scenario
- High
- Engineering practice
- Performance regression · Release verification
Estimated field mix
- Performance engineering50%
- Quality engineering30%
- Site reliability20%
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 freight broker sees slow quote responses at dispatch handover. The service looks healthy in average-latency charts, yet a few long requests occupy every worker. Build a small synthetic quote service and controlled dependency stub before taking implementation tickets.
Setup prerequisites
- Create a local quote endpoint and a deterministic carrier-price stub; no repository or dataset is supplied.
- Use synthetic routes and a fixed workload manifest. Record runtime, machine resources and instrumentation settings.
Preceding work
Complete these dependencies, or supply their agreed outputs before taking this ticket.
- PLATENCY-101 · Write down the traffic mix before comparing quote timings
- PLATENCY-103 · Separate quote queue time from carrier lookup time
- PLATENCY-104 · Remove repeated tariff parsing from the quote hot path
- PLATENCY-102 · Show quote latency percentiles alongside rejected and timed-out requests
- PLATENCY-105 · Stop expired quotes from holding carrier connections
- PLATENCY-106 · Bound parallel carrier lookups without serializing every quote
- PLATENCY-108 · Choose an overload policy from the quote deadline budget
- PLATENCY-109 · Make the quote benchmark fail when the generator cannot keep up
Acceptance criteria
- Use the fixed workload and three paired runs after warmup; report all runs and median p99 with spread.
- For this exercise require unchanged fixture outputs, no higher timeout rate and at least 15% lower median p99 at the declared baseline arrival rate.
- Mark an unstable or generator-invalid result inconclusive and stop promotion; retain the prior configuration and a documented rollback command.
Implementation constraints
- The 15% threshold is an exercise acceptance budget on the declared machine, not a universal performance promise.
Verification to include
- Run the candidate and baseline in alternating order and retain raw histograms and output comparisons.
- Introduce a known pricing regression and a deliberately slow candidate separately; both must block the release gate for the relevant reason.
Deliverables
- Repeatable release check, run artifacts and rollback rehearsal notes
Rollout and recovery
Promote only within the synthetic environment after the gate passes; restore the previous configuration and repeat the same workload to verify recovery.
Value of the work
For the engineer: Learn to distinguish queueing, dependency delay, CPU work and measurement mistakes using reproducible observations.
For the team: Produce a reviewable diagnosis and guarded changes that could guide a team investigating customer-visible latency.
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.