Capacity Load Test Plan for Brokerage Infrastructure

Describe demand in operational units

Separate connected sessions from active requests. A thousand idle sessions may create less processing than a small group repeatedly generating large statements. Record login bursts, order and amendment arrivals, subscribed instruments, update frequency, subscriber fan-out, payment callbacks and reporting jobs as distinct demand components.

Describe data size and state too: accounts with long histories, cold caches, realistic permission checks and pending queues can behave differently from empty test accounts. Use synthetic or appropriately protected test data. Ask each external provider which test endpoint, rate limit and authorized load scope applies before directing traffic at it.

Choose a load model that exposes the question

A closed workload starts new work as simulated users finish earlier work. An open arrival model schedules new work independently of completion. Grafana's k6 documentation explains why a closed model can reduce offered load when the system slows, hiding pressure that a fixed arrival-rate scenario intends to test.

Neither model is universally correct. A user who waits before clicking again and a provider that keeps sending callbacks represent different demand patterns. Specify which behavior each scenario represents and monitor whether the load generator actually delivered it. Dropped test iterations or a saturated generator must appear in the results.

Define evidence before running

For each path, set approved latency, error and correctness criteria, with a measurement window and minimum sample size. Observe resource saturation and queue age as well as response time. Google SRE guidance distinguishes latency, traffic, errors and saturation; adapt those categories to the component rather than copying an arbitrary benchmark.

Include ramp-up, sustained operation and recovery after the load falls. A system that responds quickly while silently losing callbacks has failed. Keep immutable run identifiers, code/configuration versions, input profiles and raw measurements. Compare runs only after explaining hardware, deployment and workload differences.

Example: a fictional mixed workload

An operator proposes a 20-minute test with 600 connected sessions, 40 order events per second, 200 price updates per second each delivered to an average of 50 subscribers, and two concurrent statement exports. The simple fan-out estimate is 10,000 update deliveries per second before batching or filtering. These are test inputs, not vendor capacity claims. The team checks each path separately and repeats the scenario with exports disabled to investigate contention.