Scalability, Reliability, and Availability Best Practices
Learn how to plan Twilio Programmable Voice implementations that scale to high call volumes while remaining reliable and available. This guide covers capacity planning, enterprise network topology, high-scale SIP routing, number pool optimization, and resilient state management. Use it when you're designing large or XXL-scale deployments, such as high-volume contact centers, PSTN connectivity, or self-service automation applications.
This guide focuses on planning for scale. For strategies to handle component failures, carrier outages, and connection disruptions, see Programmable Voice Failover Best Practices. The two guides are complementary: scale planning helps you size and architect your deployment, while failover planning helps it degrade gracefully when something goes wrong.
Scaling a voice implementation is about more than raw throughput. As call volume grows, small inefficiencies in capacity planning, network topology, or state management compound into reliability problems. This guide describes architectural patterns and configuration strategies for large-scale, high-reliability deployments.
The sections below are broken up into functional areas. The recommendations are largely independent of each other, so review the sections that apply to your use case and adopt the guidance that's relevant to your architecture.
- Capacity planning and throughput management
- Enterprise network architecture and interconnects
- High-scale SIP proxy architecture
- Number pool optimization
- Resiliency, state management, and fallbacks
Accurate profiling of your concurrent call volume and routing limits is critical to supporting high-scale implementations.
Before you scale, characterize your traffic. Determine your peak concurrent calls, your average call duration, and whether your traffic is sustained or event-driven. Event-driven traffic — such as batch or campaign dialing — creates a spiky calls-per-second (CPS) profile that requires different capacity planning than steady, sustained traffic.
Use the Call Insights Dashboard to measure your historical call volume and average length of call (ALOC), and to filter trends by call direction, call type, and region. For programmatic access to the same aggregated metrics, use the Voice Insights Reports API.
Understand your outbound throughput limits. Twilio enforces a default CPS limit on outbound calls, and you must notify Twilio if your peak volume exceeds 5 CPS so that your account can be provisioned appropriately.
Warning
CPS thresholds and the process for requesting an increase can change. Confirm the current limit and the notification process for your account with your Twilio account team before you plan around a specific number.
Twilio CPS limits apply to outbound REST API requests, such as Calls.create(). Calls initiated from a client SDK using Voice.connect() are exempt from CPS throttling.
If your architecture relies exclusively on SDK-initiated outbound calls, you don't need to request or self-serve a CPS increase.
For high-volume, enterprise-grade reliability, standard public internet routing may not be sufficient.
Use private Twilio Interconnect connections to route high-volume traffic off the public internet. Standard interconnect capacities are available through the normal provisioning process. Higher-capacity connections, such as 10 Gbps, are non-standard and require specialized approval from the Interconnect team, along with potential review by other teams depending on your traffic profile.
For high availability, connect to at least two geographically redundant Twilio Exchange locations. See Connect to multiple Twilio Exchange locations in the failover guide.
Direct hardware co-location — placing your equipment in Twilio racks — is not permitted, due to security and scaling constraints. Instead, connect your equipment to Twilio's infrastructure using cross-connects.
Optimize your network topology so there are as few hops as possible between the internet and your Session Border Controller (SBC). Aim for 2–3 hops. A topology with 6 or more hops introduces 6 potential points of failure and is considered high risk.
If you place load balancers in the SIP path, make sure they're configured to handle SIP INVITE traffic correctly. Misconfigured load balancers or reverse proxies can disrupt SIP headers, fail to pass SIP traffic, and introduce Application Layer Gateway (ALG) risks.
Direct SIP dialing between standard accounts can hit routing limitations or be blocked at scale.
To handle high volumes and retain full control over routing, deploy your own scalable SIP proxy — such as Kamailio or FreeSWITCH — outside of Twilio. A custom SIP proxy lets you:
- Retain full control over SIP headers and routing logic.
- Securely support multiple downstream customer platforms simultaneously.
- Enable advanced operations, such as SIP
REFER, at scale.
If your application relies heavily on VoIP and proxy numbers — for example, gig-economy delivery platforms or large contact centers — optimizing your number pool is essential to scaling efficiently and avoiding carrier spam filters.
Don't allocate proxy numbers on a 1:1 per-session basis. Instead, allocate one proxy number per concurrent active user — for example, per driver on shift. A single number can handle multiple overlapping active sessions, which can reduce the size of your required phone number pool by 5 to 10 times.
Large number pools can trigger carrier spam filters during traffic ramp-ups for carriers such as AT&T or Hiya. Before you go live, assign all numbers to a Branded Calling bundle at the parent account level so your calls are properly attributed.
At high scale, seamless failure recovery is mandatory to maintain reliability. The following patterns help you recover from failures without trapping users in bad states.
Build robust fallback decision trees for VoIP pushes. If a VoIP push results in a no-answer, failed, or busy status, immediately route the call to a PSTN fallback — such as a driver's cell phone — or to a Studio IVR fallback flow for voicemail or customer care.
At scale, stale or desynchronized state can trap users in unusable states. Guard against the following common failure modes:
- Stale registrations: If an app is killed without logging out, the session record can remain active while the SDK is unregistered. Rely on a predefined timeout — for example, a 20-second
<Dial>timeout— to automatically route the call to your fallback mechanism. - Flag desync: If an app crashes mid-call, boolean flags such as
driver_on_callcan become desynchronized and trap the user in a "busy" state. Implement a time-to-live (TTL) guard based on your maximum allowed call duration, and clear flags whenever a user logs in.
Match the TTL of your access tokens to the application's session lifetime — for example, a 14-hour working shift, capped at a maximum of 24 hours. Scoping token lifetimes to sessions helps prevent unauthorized access and zombie sessions. Generate tokens securely on the server side using an API Key and Secret.
Explore the following guides to build on what you've learned here:
- Programmable Voice Failover Best Practices: Configure your systems to handle component failures, carrier outages, and connection disruptions.
- Programmable Voice limits: Review the limits that apply to Programmable Voice.