Meridian Field Services: instructional example, not project evidence
Every number below was committed in the architecture and is cited by id. Were no targets committed, this artifact would not exist; load-testing against invented numbers is theater.
Instantiates: board liveness[1] (job visible ≤5 s p95), feed-loss resilience[1] (zero blocked assignments), and the scale frame: five hubs, 1,500 jobs/day, 400 positions/minute, first bottleneck expected at adapter fan-in beyond 2,000 positions/minute: restated by reference, never re-derived. Scope this phase: liveness, fan-in, burst; agreed with E. Sandoval.
Model before rates, with the reason it matches real traffic. The script is the executable truth; criteria here carry the verified-at-commit stamp against its threshold block.
| Scenario | Type | Model (reason) | Rate / ramp / duration | Dataset | Criteria (source) | Script |
|---|---|---|---|---|---|---|
| PS-1 board liveness | baseline + load | open arrival: jobs arrive from the world; dispatchers do not queue behind each other | 4 jobs/min · ramp 5 min · steady 20 min | 300-vehicle synthetic fleet · 500k position rows (volumetrics[2]) | job-visible p95 ≤ 5 s (board liveness[1]) | perf/board_liveness.js · k6 · perf-nightly[5] |
| PS-2 shift-start spike | spike | open: the 7 a.m. burst is arrival-shaped (observed pattern[6]) | burst 20 jobs/min · 10 min over baseline | same | PS-1 criteria hold + suggestion latency inside its budget (sub-second[1]) | perf/shift_spike.js |
| PS-3 adapter fan-in | breakpoint | open arrival ramp: vendor push shape | 400 → 2,500 positions/min · 300 steps · until failure condition (stale > 5% for 60 s) | same | settle the 2,000/min hypothesis (scale frame[1]) | perf/adapter_breakpoint.js |
| PS-4 pilot-day soak | soak | open at average load | 4 hours steady | same + full-day job churn | no latency creep, no pool exhaustion (caching risk flag[1]) | perf/day_soak.js |
| Type | Disposition | Basis |
|---|---|---|
| Baseline + load | always: PS-1 carries both at this scale | n/a |
| Spike | engaged · PS-2 | The shift-start burst is the observed pattern |
| Breakpoint | engaged · PS-3 | The architecture names a first-bottleneck hypothesis to settle; breakpoint finds the ceiling, a different question from stress |
| Soak | engaged · PS-4 | Position cache + pooled connections are a named leak risk (caching decisions[1]) |
| Stress | omitted, with rationale | Graceful degradation past normal load is already exercised by the feed-loss failure-injection suite (risk prioritization[3]); redundancy is the rationale; "slow" would not be |
Parity: pilot topology (production-shaped, Toronto scale), same container layout; managed PostgreSQL one tier below production sizing, a named gap, accepted by E. Sandoval; it limits the breakpoint claim to a relative, not absolute, ceiling; re-run at production sizing before hub-six rollout (open questions[1]).
Data volumetrics: 500 thousand position rows preloaded (the 30-day working set), 1,200 open-and-recent jobs, 300 technicians, matching the data model's volumetric note[2]; an empty database predicts nothing. Ladder: the strategy's pilot tier (environments[3]), cited.
Hypothesis (inherited verbatim): first bottleneck at adapter fan-in beyond 2,000 positions/minute (scale frame[1]). Instrumentation: queue depth, adapter batch latency, dead-letter rate, database write saturation (observability signals[1]). If wrong: a database-first ceiling re-scopes PS-3's step profile and fires the architecture's revisit trigger; a higher ceiling raises confidence in the hub-six answer.
Percentiles, never means; the tail is the user experience. Each run settles or reshapes the hypothesis; distributions attach to the package.
| Scenario · run | Target | Actual (p95 / p99) | Delta | Verdict |
|---|---|---|---|---|
| PS-1 · 2026-09-12 (commit-stamped) | ≤ 5 s p95 | 3.8 s / 4.6 s | −1.2 s | pass |
| PS-3 · 2026-09-12 | hypothesis: 2,000/min | failure condition at 2,150/min | +7.5% | hypothesis CONFIRMED within tolerance; ledger updated; the adapter revisit trigger stands |
Full distributions and the soak time series attach (perf run exports[4]), referenced never inlined. Re-runs: before the release gate (CI gates[3]), after any scale-frame change, monthly during hub rollout.
| Question | Owner | Answer by | Blocks |
|---|---|---|---|
| Does the breakpoint re-run at production database sizing move before or after the hub-six decision? | E. Sandoval | Aug 15, 2026 | The absolute-ceiling claim only |
Omission note (no committed targets): "performance_test_scenarios omitted for this project: the architecture commits no numeric performance targets; load-testing against invented numbers is theater. Recorded in adaptation event #1."