Skip to content

Performance Engineering

Performance is an ility selected at shaping time, not a polish step at the end. Load profile, target, bottleneck — named in the brief, verified in the pipeline, watched in production.

Owners: Tech Lead, Developer Phase it lives in: What We Build → How We Build The corpus principle this enacts: UX/product ilities are first-class requirements.

Where it lives in the chain

How to do this

A performance target is specific and witnessed:

  • Load profile"Gal grades 30 exams in a session. Peak: 200 graders submitting simultaneously at end of semester." Not "a lot of users."
  • Latency targetp95 submit under 800ms. Per critical flow, not system-wide.
  • Throughput target200 submissions per second sustained.
  • Bottleneck hypothesis"The grading service is CPU-bound during scoring; the database write is the second bottleneck." Tested, not guessed.
  • SLO and SLASLO 99% under 800ms; SLA 95% under 1s. The buffer is the operational safety margin.

What good practice looks like

The performance work happens in three places:

  1. Shaping — the ADR names the load profile and the target. The amigos session asks "what happens at the target load? what happens at 2×?"
  2. Pipeline — a load test runs against staging at the SLO target before release. A failed load test blocks the release.
  3. Production — the SLI is watched; SLO breach pages on-call. The first 48 hours after release watches the latency dashboards.

A team that optimises before measuring is a team that optimises the wrong thing. The wallet bug's blast radius was emotional, not performance. The JWT outage's cause was configuration, not latency. Performance issues, when they ship, do so loudly — and the SLI catches them before the user does.

200apps · How We Work · NWIRE