Skip to content

Source Capacity Load Test

Capacity stress test (diagnostic) — instantiates Target-Complete Mapping Design

Drives a source to the realistic peak demand of all its assigned targets to confirm it can actually serve at load — and that it degrades safely rather than silently dropping coverage when overwhelmed.

A source that "covers" five hundred targets on the map may buckle at two hundred at once. Source Capacity Load Test subjects a source to the realistic peak demand of all the targets mapped to it, measuring whether it sustains service at the required level and — past that level — whether its degradation-and-fallback behavior engages instead of failing silently. Its defining move is to attack the gap between formal coverage and operational coverage: the binary matrix says green, but the source is overloaded for a slice of targets whenever demand spikes. It verifies the fallback, not just the happy path.

Example

A tax agency's e-file service nominally covers every filer. That is comfortably true in March; the real target load arrives on the filing deadline. The load test replays a deadline-day traffic profile — well above average volume — against the system. At roughly three times average load, submission latency crosses the point where filings begin to time out: the source is formally complete but operationally overloaded for a meaningful fraction of filers at peak. The test then probes the fallback — does the system queue and confirm ("received, processing delayed"), or drop submissions silently? It drops silently, the worst case, because a lost filing looks identical to one that was never attempted. The outcome is to provision for the true peak with margin and to add a visible queue fallback, then re-test.

How it works

What distinguishes this test is assigned-load stress plus fallback verification, not a functional check at nominal volume. It builds a demand profile from the targets mapped to the source — peak, not average — drives the source to and past that level, measures the service level (latency, throughput, error rate) against the coverage contract, locates the degradation "knee," and confirms that the graceful-degradation or fallback rule actually triggers and stays visible at overload rather than shedding coverage in silence.[1]

Tuning parameters

  • Load profile — average vs peak vs surge. The profile you choose is exactly the capacity you certify; under-scope the peak and you certify fragility.
  • Capacity margin — the headroom above expected peak a source must hold before it passes.
  • Traffic realism — synthetic generated load vs a shadow of real production traffic, which exposes hot spots synthetic load misses.
  • Degradation criteria — what counts as safe degradation (queue, throttle, escalate) versus silent loss.
  • Duration — a short spike vs a sustained soak; soak tests reveal leaks and slow exhaustion a spike hides.

When it helps, and when it misleads

Its strength is exposing the overloaded-source deception that a binary coverage matrix rates green, and forcing fail-safe behavior into the open where it can be checked. Its failure mode is that a load test only certifies the profile it was given — an optimistic profile certifies a fragile system — and it measures the source in isolation, missing contention with other sources that share the same infrastructure. The classic misuse is testing at average load to earn a passing capacity certificate for a system that has never seen its real peak. The discipline that guards against it is to profile the true peak with margin, and to pair the test with a dependency view so shared-bottleneck contention is not missed.

How it implements the components

Source Capacity Load Test realizes the operational-viability slice of the archetype — the components a stress test can establish:

  • feasibility_and_capacity_check — its core result: whether the source can actually serve all assigned targets at realistic peak load, not merely in principle.
  • degradation_and_fallback_rule — it drives the source past its limit specifically to confirm the fallback engages and fails visibly rather than dropping coverage silently.

It does not check whether ≥2 independent witnesses survive a failure (that's Redundancy N+1 Check), whether a witness is valid at all (Witness Validation Test), or which minimal set of sources to deploy (Set-Cover Analysis).

References

[1] Little's Law (L = λW) relates the average number of items in a system to the arrival rate times the time each spends in it; it is the standard sanity check for reading a capacity test — for instance, inferring the concurrency a source must hold to serve a given arrival rate within a target latency, and thus how far the tested peak sits from the real one. ↩