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.[n1]
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).
Related¶
- Instantiates: Target-Complete Mapping Design — it distinguishes formally-complete coverage from coverage that survives real load.
- Consumes: Set-Cover Analysis — supplies the source→target assignment whose peak demand defines the load profile.
- Sibling mechanisms: Redundancy N+1 Check · Set-Cover Analysis · Witness Validation Test · Coverage Dashboard · Service-Area Gap Analysis
Editorial Notes¶
Form Classification¶
Form family: Experiment, Test & Rehearsal
Rationale: Source Capacity Load Test operates as an active test, trial, simulation, drill, or rehearsal that generates evidence through a deliberate attempt or perturbation because it 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.
Independent corroboration: The frozen evidence defines Source Capacity Load Test as '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', so its operative form is Experiment, Test & Rehearsal.
Nearest alternative: Assessment, Review & Assurance — Source Capacity Load Test includes features of a bounded evaluation of existing evidence or work that produces a finding or disposition, but its defining operation is an active test, trial, simulation, drill, or rehearsal that generates evidence through a deliberate attempt or perturbation.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Engineering & Design
Origin pattern: Convergent development
Present-day reach: Universal
Rationale: Driving a provider to realistic peak assigned demand and observing safe degradation is engineering load and stress testing.
Related originating lineages:
- Computer Science & Software Engineering — Performance testing measures throughput, latency, and failure under load.
- Operations Research — Queueing models relate demand, service capacity, and dropped coverage.
- Organizational & Management Science — Staffed services require capacity and escalation plans at peaks.
- Systems Thinking & Cybernetics — Systems thinking, feedback control, and cybernetics supplies a parallel or contributing lineage for the mechanism's defining operation: 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….
Review resolution: The blind reviewers agree that engineering_design is the primary origin and differ only on alternate origin disagreement. I preserve every independently explained alternate from both records rather than imposing a numeric cap. I retain convergent because the combined evidence shows independent disciplinary development. The broader reach of universal records portability separately from historical provenance; encyclopedia_synthesis=true preserves the affirmative synthesis judgment where either reviewer identified one.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; medium confidence.
Notes¶
[n1] 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. ↩