"How many agents can this server handle?" is the question I get most often, and it's close to unanswerable as asked. Agent count is a poor predictor of load. Two floors of 300 agents can differ by an order of magnitude in what they demand of the platform, depending on how hard they dial and what they do with the results.
A more useful frame is: what breaks first, and in what order.
The order of failure
Roughly, on a single-server build being pushed past its comfort zone:
1. The database. Almost always first. Not on raw capacity — on lock contention and on reporting queries competing with live dialing for the same tables. Someone opens a report covering last quarter, and agent screens stall.
2. Asterisk channel capacity. Concurrent channels, not calls per hour. This is the one people plan for, and it's usually not the binding constraint until later than expected.
3. The web tier. Agent screens poll. Multiply the polling interval by the agent count and you get a request rate that's easy to underestimate and that scales linearly with headcount.
4. Carrier-side limits. Channel caps and per-second call limits you didn't know were in the contract, discovered at your busiest hour.
The lesson buried in that ordering: the first thing to break is not the telephony. It's the database, and specifically it's reporting sharing infrastructure with dialing.
Split reporting off before you split anything else
The single highest-leverage change on a growing platform is to stop letting reports touch the live database. A replica that reporting reads from, with dialing untouched on the primary, removes an entire class of "the system froze at 2pm" incidents — and 2pm is when the supervisor pulls the midday numbers.
This is cheap. It's usually one machine and a few hours. It buys more headroom than a bigger dialer will.
Concurrent channels, not agents
Once you're planning capacity properly, count channels. A predictive campaign at a 3:1 ratio with 200 agents is asking for 600 concurrent channels at peak, plus inbound, plus whatever recording and monitoring add.
Plan against peak, not average. Averages hide the fifteen minutes a day where everything happens at once, and the fifteen minutes is what your customers experience.
Add dialers before you add cores
Past a certain point, a bigger single dialer stops helping. Multiple dialers behind a shared database scale further, fail more gracefully, and let you take one out of rotation for maintenance without going dark.
The threshold varies by workload, but the signal is consistent: when your dialer is spending real time in interrupt handling and channel setup latency is creeping up under load, more cores on the same box is a smaller win than another box.
The corollary matters more. A cluster you can remove a node from is a cluster you can patch during business hours. A single server is a system where every upgrade is a scheduled outage, and scheduled outages get deferred until they become unscheduled ones.
What I'd build for 1,000+ agents
- Separate database primary, with a replica dedicated to reporting.
- Multiple dialers, sized so that losing one degrades rather than stops you.
- A web tier that can scale horizontally, behind a load balancer.
- At least two carriers with automatic failover, tested by actually failing one over.
- Recording storage on its own volume, because it grows without bound and fills disks that other things need.
None of that is exotic. What makes it work is the boring part: the failure modes were tested deliberately rather than discovered in production.
The mistake I see most
Scaling by making the one server bigger, until it can't be made bigger.
The rebuild that follows is always harder than the incremental split would have been, because by then there's a floor of agents depending on it and no window to do the work. The right time to move from one server to a cluster is while you still have the slack to do it calmly.