toolbox
Home / AI, Data & Technology / A B Experiment Processing Capacity Estimator

A B Experiment Processing Capacity Estimator

Estimate the processing capacity required to assign, log, and analyze A/B experiment traffic. The calculator starts with incoming experiment events per second, applies an event multiplier and peak factor, then adds capacity headroom to produce a target processing rate. This model is useful for experiment infrastructure where one user action can create several assignment, exposure, conversion, or telemetry events. It makes peak amplification and engineering headroom explicit so a service can be sized above average traffic rather than being planned only around nominal request volume.

Inputs

events/s
×
×
%
events/s
Result
—
target processing capacity
Peak event rate—
Recommended workers—
Headroom capacity—

1. Enter base traffic
Use the average rate that drives experiment events, measured on the same time basis as worker capacity.

2. Set event amplification
Account for multiple logs or records generated from one assignment or user action.

3. Model the peak
Multiply average demand by an observed or planned peak-to-average factor.

4. Add headroom
Reserve extra throughput for growth, retries, imbalance, or operational uncertainty.

5. Enter worker capacity
Use a measured sustainable rate per worker to estimate the number of processing units required.

Target capacity = Base traffic × Events per unit × Peak factor × (1 + headroom rate)

All rate terms are expressed as events per second after multiplication. Recommended workers equals target capacity divided by the sustainable processing capacity of one worker, rounded up.

This is a throughput model, not a queueing simulation. Storage writes, partitioning, retries, batch flushes, network limits, latency SLOs, and uneven key distribution can require additional capacity.

What the result means

Use the main result together with the supporting statistics and the stated assumptions; it is a planning estimate rather than a guarantee.

Keep units and the unit of analysis consistent. Recalculate when traffic patterns, rates, priors, sample sizes, or design assumptions change.

Given

  • Base traffic: 5,000 events/s
  • 3 experiment events per traffic unit
  • Peak factor: 2×
  • Headroom: 25%
  • Worker capacity: 2,500 events/s

Calculation
Peak rate = 5,000 × 3 × 2 = 30,000 events/s. Target = 30,000 × 1.25 = 37,500 events/s. Workers = ceil(37,500 ÷ 2,500) = 15.

Result
37,500 events/s and 15 workers

Interpretation
The system should sustain about 37.5k events/s under the modeled peak while preserving 25% capacity headroom.

What should count as an experiment event?

Use the unit consumed by your processing pipeline, such as assignment, exposure, metric, or telemetry records. Keep the definition consistent between incoming demand and worker benchmarks.

Why include both a peak factor and headroom?

The peak factor converts average demand to a modeled peak. Headroom then reserves capacity above that peak for uncertainty and degradation.

Can I use CPU utilization instead of events per second?

Not directly. This calculator needs a sustainable processing-rate benchmark per worker. CPU can help derive that benchmark through load testing.

Why are workers rounded up?

A fractional worker cannot normally provide isolated deployable capacity, so the estimate rounds up to the next whole processing unit.

Does the model account for backlogs?

No. It sizes steady processing throughput against a peak rate. Temporary bursts above capacity may still create queues, which require separate buffer and recovery-time analysis.