There comes a point where one server stops being enough, and the instinct is to buy a bigger one. That works once. The second time, you are buying an expensive machine to solve a problem that a second cheap machine would solve better, and you are still left with one thing to fail.
VICIdial clusters well, but in one specific direction: you add dialers. Everything else stays singular, and understanding that shapes every decision you make about growth.
What each machine does
The database is the shared brain. Campaigns, lists, leads, dispositions and call logs all live here, and every dialer reads from and writes to it constantly. There is one, and it is the thing that limits the whole cluster.
The web server serves the agent and administration screens. It is comparatively easy to scale and is rarely the constraint, though it is worth separating so a busy reporting query does not compete with agents loading their screens.
The dialers are Asterisk servers that place calls and bridge them to agents. These are the machines you add. Agents are distributed across them, and each dialer handles a share of the concurrent calls.
The archive server holds recordings, moved off the dialers on a schedule. Without one, recordings fill the dialers' disks, and a full disk on a dialer is an outage rather than an inconvenience.
Why the database is the ceiling
Every dialer talks to the same database. Adding a dialer adds calling capacity and it also adds database load, which means horizontal scaling on the dialer tier eventually consumes the headroom on the tier that cannot scale horizontally.
You can add dialers until the database says no. Everything about planning a large VICIdial deployment follows from that sentence.
Practically, this means the database deserves the best hardware in the cluster, the most careful tuning, and the most attention in monitoring. It also means that when a large cluster starts to feel slow, the answer is rarely another dialer. We cover how to size that machine in VICIdial server requirements.
What gets harder in a cluster
Recordings become a logistics problem
Calls are recorded on whichever dialer handled them, so recordings start life scattered. They have to be collected, moved off before disks fill, stored somewhere with enough capacity, and remain findable from the interface afterwards. Every part of that needs to work unattended, because nobody notices a broken archive job until they need a recording that is no longer there.
Configuration drift
Three dialers configured by hand over eighteen months are three slightly different machines, and the differences are invisible until one behaves oddly. Build them the same way, ideally from a scripted build rather than by hand, and change them together. Drift is what makes an intermittent fault take a week to find.
Carrier concurrency
More dialers means more simultaneous calls, and your trunk has limits whether or not they are stated clearly. Growth plans need a conversation with the carrier as well as a purchase order for a server, and it is better to have that conversation before the campaign that needs the capacity.
Time synchronisation
Machines whose clocks disagree produce reports that do not reconcile and recordings that are hard to match to calls. It is a trivial thing to get right and a genuinely annoying thing to debug later.
What stays easy
Adding a dialer is genuinely straightforward once the pattern is established, and that is the real benefit of the architecture. Capacity becomes a purchase rather than a project. Agents do not need to know which dialer they are on. And a dialer can be taken out of service for maintenance during working hours, which is close to impossible on a single-server install.
A sensible growth path
- Split the database out first. This is the highest-value move and it is the one that unlocks everything after it.
- Separate the web server. Cheap, and it stops reporting queries competing with agent screens.
- Add the second dialer before you need it. Doing it under pressure, during a campaign, is how mistakes get made. Doing it calmly also proves the process works.
- Stand up the archive server at the same time. Two dialers producing recordings is the point at which manual housekeeping stops being viable.
- Then monitor the database as the leading indicator. Its load, not the agent count, tells you when the next expansion is due.
The judgement call
Clusters are more capable and more complicated. Three machines have more ways to be subtly wrong than one, and they need somebody who understands the whole picture rather than each part. If you are running forty agents comfortably on a split database and dialer, adding cluster complexity for its own sake buys you nothing but surface area.
Grow when the numbers say to, in the order above, and the ceiling stays where it should be: on the database, visible, and planned for.
We design, build and operate VICIdial clusters, including untangling ones that grew by accident. See call centre setup or book a free consultation if you are approaching the limit of a single box.