# How Many Masked Numbers Do You Need? Pool Sizing and Rotation

> How to size a masked number pool - the concurrency formula, why order volume is the wrong input, number rotation, cooldown, and what happens when the pool runs dry.

Source: https://edesy.in/blog/how-many-masked-numbers-do-you-need-2026

**Short answer:** you need enough numbers to cover **peak concurrent sessions**, not total orders.
A masked number represents one active pair at a time and returns to the pool when that session
ends, so a platform running 10,000 orders a month with two-hour sessions needs tens of numbers,
not thousands. Get the estimate wrong in the tight direction and session creation starts failing
at exactly your busiest hour.

## The Arithmetic

The input everyone reaches for first — monthly order volume — is the wrong one. The right one is:

> **Peak concurrent sessions** = orders during your busiest window × average session lifetime ÷
> length of that window

Work it through. A delivery platform does 800 orders on a Friday evening between 7pm and 10pm.
Each session lives about 45 minutes.

- Busy window: 3 hours
- Orders in it: 800
- Average session: 0.75 hours
- Concurrent ≈ 800 × 0.75 ÷ 3 ≈ **200 sessions live at once**

So roughly 200 numbers, plus headroom — not 800, and certainly not the monthly order count.

Two things move this number more than anything else:

**Session lifetime dominates.** Halving how long sessions stay open halves the pool. If you end
sessions on delivery rather than letting them expire on a timer, you cut the requirement directly.
This is the single biggest lever and it costs nothing.

**Peak, not average, sets the floor.** Sizing to your daily average guarantees failure at peak.
Size to the worst hour you actually expect, then add headroom.

## Rotation and Cooldown

When a session ends the number goes back to the pool and can be reused. That reuse is what makes
a small pool serve a large platform — but it introduces one problem worth designing for.

If a number is reassigned immediately, a late call from the *previous* pair can land on the
*new* pair. The buyer from the last order rings back twenty minutes later and reaches a stranger.

The mitigation is a **cooldown**: keep a number out of circulation briefly after a session ends.
Cooldown costs pool size — numbers sitting idle are numbers you are paying for — so it is a
deliberate trade between pool cost and cross-talk risk, not a setting to max out.

See [number pooling](https://edesy.in/number-masking/features/number-pooling) for how pools are managed, and
[scaling number masking](https://edesy.in/number-masking/guides/scaling-number-masking) for the operational view.

## What Running Dry Looks Like

Under-provisioning does not degrade gracefully. It fails abruptly, at peak, and it does not look
like a telephony problem:

- Session creation starts returning errors during your busiest hour.
- Orders get created with no contact path attached.
- Support sees "the agent never called" complaints that are really allocation failures.
- Your monitoring shows a healthy voice platform, because no call was ever attempted.

Two defences. **Alert on pool utilisation, not on call failures** — utilisation crossing ~80% is
the signal, and by the time calls fail you are already past it. And **decide the degradation
path** before you need it: an order that cannot get a masked number should either queue, fall back
to a monitored support line, or fail loudly. Silently creating an uncontactable order is the worst
of the three, and it is the default if nobody chooses.

## Number Health

Not every number in a pool behaves identically forever. Numbers can develop problems — carrier
issues, reputation, downstream filtering. A pool that tracks per-number health lets you take a bad
number out of rotation rather than discovering it through a pattern of complaints that took a
month to notice.

Track connect rate per number. A number that connects noticeably worse than its peers is telling
you something before your customers do.

## Practical Starting Point

If you are launching and have no real data:

1. Estimate concurrent sessions from your busiest expected hour, using the formula above.
2. Add roughly 30% headroom for estimation error and cooldown.
3. Instrument pool utilisation from day one.
4. Re-size after two weeks of real traffic rather than guessing twice.

Starting small and growing is fine — the failure mode is not noticing you need to grow.

## What Pooling Does Not Do

- It does not stop two parties exchanging real numbers on the call.
- Cooldown reduces cross-talk risk; it does not eliminate a determined callback.
- Pool size does not affect call quality — a busy pool does not produce worse audio, it produces
  failed allocations.

## Related Reading

- [Number masking for marketplaces and gig platforms](https://edesy.in/blog/number-masking-for-marketplaces-gig-platforms-2026)
- [One-way vs two-way masking](https://edesy.in/blog/one-way-vs-two-way-number-masking-2026)
- [What number masking costs in India](https://edesy.in/blog/what-number-masking-costs-india-2026)
- [Number masking for delivery and logistics fleets](https://edesy.in/blog/number-masking-delivery-logistics-fleets-2026)
- [Scaling number masking](https://edesy.in/number-masking/guides/scaling-number-masking)