Proxy Allocation for Releases: Working Out How Many You Need

Ask how many proxies a release needs and the usual answer is a number with no reasoning attached. The number depends on four things you can estimate beforehand, and estimating them is faster than guessing and considerably cheaper than over-buying.

The four inputs

Four quantities determine the answer, and none requires special knowledge: how many entries you intend to submit, what proportion you expect to survive to checkout, how tolerant the target is of repeated addresses, and how much of the result you are prepared to lose to a single failure.

The fourth is the one people leave out, and it is the reason concentrated setups disappoint. Putting everything on eight addresses from one subnet is a single point of failure wearing a costume — one range-level action removes the entire attempt at once.

Addresses per task

The default should be one address per task, with no sharing at checkout.

Sharing is tempting because addresses cost money and tasks are cheap to duplicate. The problem is correlation: two tasks on one address are not two independent attempts, they are one attempt counted twice. A flag on either applies to both, so the second adds cost without adding expected yield.

Monitoring is the exception and should be reasoned about separately. A monitor polls one endpoint continuously and needs almost nothing from its address other than that it still responds. Monitors can share freely, provided they never touch the addresses reserved for checkout.

Regional allocation

Regional releases resolve availability from the visitor's location, so addresses in the wrong country are not disadvantaged entries — they are not entries at all.

Where a release spans several countries, allocate proportionally to where stock is expected rather than evenly. Even splits feel fair and are usually wrong: they put the same weight on a market with a hundred pairs as on one with a thousand.

Within a country, city-level spread is worth having but matters less than provider spread. Twenty addresses across four providers survive a provider-level action; twenty in one city on one network do not.

Budgeting against expected yield

Work backwards from the outcome. If a release historically converts one entry in twenty into a completed order, and you want two, you need roughly forty credible entries — and "credible" is load-bearing, because forty entries on recycled addresses are not forty chances.

Now compare that address cost against what the outcome is worth. This arithmetic frequently shows the whole attempt is not worth running, which is a useful result rather than a discouraging one. The releases worth entering are the ones where it clears comfortably, and identifying them in advance is cheaper than discovering it afterwards.

Pay-per-IP pricing makes this easier to reason about than bandwidth pricing, because the cost side is fixed and known before the release rather than measured after it.

Measuring afterwards

Record four counts per release: entries attempted, entries reaching checkout, entries challenged, entries completed. Tag each with region and address type.

One release tells you nothing. Four start showing structure, and the structure is usually concentrated: one region underperforming, one batch of addresses carrying most of the challenges, one provider quietly failing. Those are all actionable. "It went badly" is not.

The most common thing this reveals is that the failures were not spread evenly at all, which means the fix is targeted rather than "buy more".

Where more addresses stop helping

Additional addresses stop adding yield at the point where something else is the constraint — and after a certain scale, something else usually is.

If entries are failing because the checkout flow is slow, or because payment details are being rejected, or because the tasks are all firing in the same millisecond in a way no human population would, then more addresses buy nothing. The post-release counts identify which constraint is binding: if the challenge rate is low but the completion rate is also low, the problem is downstream of the proxies entirely.

This is worth checking before every increase in spend, because address count is the easiest thing to raise and often the least effective.

FAQ

Is one address per task really necessary?

At checkout, yes — shared addresses are correlated failures. For monitoring, no.

How much spare capacity should I hold?

Enough to replace the fraction you historically lose to challenges. Your own records answer this better than any general figure.

Does spreading across providers matter more than across cities?

Usually yes. Actions tend to land at the network level rather than the municipal one.

What if I have no history to estimate from?

Run a deliberately small first attempt and treat it as measurement. It costs less than a large attempt built on a guess.