--- "@context": https://schema.org "@type": TechArticle "@id": https://www.twilio.com/docs/voice/twilio-voice-scalability-reliability-availability#article headline: Scalability, Reliability, and Availability Best Practices description: Plan highly scalable, reliable, and available Twilio Programmable Voice architectures, including capacity planning, network topology, SIP proxying, number pool sizing, and resilient state management. url: https://www.twilio.com/docs/voice/twilio-voice-scalability-reliability-availability inLanguage: en dateModified: 2026-11-04T18:18:17.000Z author: "@type": Organization name: Twilio Developer Education Team publisher: "@type": Organization name: Twilio --- # 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](/docs/voice/twilio-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. ## Overview 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](#capacity-planning-and-throughput-management) * [Enterprise network architecture and interconnects](#enterprise-network-architecture-and-interconnects) * [High-scale SIP proxy architecture](#high-scale-sip-proxy-architecture) * [Number pool optimization](#number-pool-optimization) * [Resiliency, state management, and fallbacks](#resiliency-state-management-and-fallbacks) ## Capacity planning and throughput management Accurate profiling of your concurrent call volume and routing limits is critical to supporting high-scale implementations. ### Assess your call volume profile 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](/docs/voice/voice-insights/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](/docs/voice/voice-insights/api/reports-api). ### Monitor and plan for Calls Per Second (CPS) 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. #### SDK-initiated calls are exempt from CPS limits Twilio CPS limits apply to outbound REST API requests, such as [`Calls.create()`](/docs/voice/api/call-resource#create-a-call). 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. ## Enterprise network architecture and interconnects For high-volume, enterprise-grade reliability, standard public internet routing may not be sufficient. ### Use dedicated interconnects for high-volume routing Use private [Twilio Interconnect](/docs/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](/docs/voice/twilio-voice-failover-best-practices#connect-to-multiple-twilio-exchange-locations) in the failover guide. ### Understand physical infrastructure limitations 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. ### Minimize network hops 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. ### Configure load balancers to handle SIP correctly 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. ## High-scale SIP proxy architecture 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](https://www.kamailio.org/) or [FreeSWITCH](https://freeswitch.com/) — 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. ## Number pool optimization 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. ### Size proxy numbers by concurrent users, not sessions 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. ### Warm up numbers and avoid carrier filtering 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](/docs/voice/branded-calling) bundle at the parent account level so your calls are properly attributed. ## Resiliency, state management, and fallbacks 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 VoIP to PSTN/IVR fallback trees 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](/docs/studio) IVR fallback flow for voicemail or customer care. ### Manage state defensively 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 [``](/docs/voice/twiml/dial#timeout) `timeout` — to automatically route the call to your fallback mechanism. * **Flag desync**: If an app crashes mid-call, boolean flags such as `driver_on_call` can 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. ### Scope token lifecycles to sessions Match the TTL of your [access tokens](/docs/iam/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](/docs/iam/api-keys). ## Next steps Explore the following guides to build on what you've learned here: * [Programmable Voice Failover Best Practices](/docs/voice/twilio-voice-failover-best-practices): Configure your systems to handle component failures, carrier outages, and connection disruptions. * [Programmable Voice limits](/docs/voice/programmable-voice-limits): Review the limits that apply to Programmable Voice. ## Related reference documentation Find reference documentation for the topics on this page. * [Programmable Voice API Overview](/docs/voice/api) * [Twilio Interconnect](/docs/interconnect) * [SIP for Programmable Voice](/docs/voice/api/sip-interface)