Scaling Healthcare RTC: When CPaaS Stops Being Enough

ecosmob — Fri, 08 May 2026 09:37:31 +0000

If you're building real-time communication into a healthcare product, you'll hit a wall. Not in week one, not in month six, but somewhere around the point where concurrent sessions go from hundreds to thousands and the CPaaS invoice starts looking like a salary.

This post is a practical breakdown of when to stay on CPaaS, when to migrate to custom RTC infrastructure, and what the architecture actually looks like under load.

TL;DR

CPaaS is the right starting point for most teams. Don't over-engineer day one.
The transition from CPaaS to custom RTC is a phase, not a switch. Hybrid is normal.
Capacity planning in healthcare must size for peak burst, not average load.
The triggers for migration are usually cost curves, control limits, or compliance — in that order of frequency.

The communication stack you're actually running

Most healthcare comm stacks aren't a single channel. They're a sequence:

Video consultations — WebRTC, the visible layer
Voice (VoIP + PSTN fallback) — when video fails or isn't viable
SMS / WhatsApp — high-volume reminders and nudges
Secure in-app chat — async between visits
IVR — first-touch routing and triage
Store-and-forward async — patient updates, images, queries

Each channel works in isolation. The hard part is the layer between them — signaling, orchestration, and context persistence.

If your stack treats these as separate pipes instead of one continuous conversation, you'll feel it the moment a video call drops to voice and the agent has no idea what was just discussed.

When CPaaS makes sense

CPaaS is genuinely the correct answer when:

Concurrent sessions are in the hundreds, not thousands
Per-minute pricing is still in rounding-error territory
You don't have an infra team that wants to run SFUs and TURN servers
Speed-to-launch matters more than per-session cost optimization

This is most early-stage healthcare products. There's no shame in it. Building media infrastructure to save money you're not yet spending is a classic mistake.

Inside The Architecture Crisis: https://www.ecosmob.com/blog/scale-patient-communication-custom-rtc/

When custom RTC starts making sense

The transition usually shows up in three signals:

1. The cost curve

CPaaS pricing is linear. Every minute, every message, every relayed media stream is metered. At low volume the meter is invisible. At scale it dominates the infra budget — and the line item grows in lockstep with usage, not efficiency.

A useful rule of thumb: if your CPaaS bill is growing faster than your engineering headcount and you can predict next year's volume within ±25%, custom RTC is probably cheaper at steady state.

2. Control limits

When you can't tune what you need to tune, you have a ceiling problem:

Can't tune SFU behavior for your specific session profile
Can't relocate TURN servers regionally
Can't enforce custom media routing logic
Can't directly observe SFU-internal metrics
Can't run isolated tenancy at the infrastructure layer

Most of these are fine — until they aren't. Once one of them is blocking a reliability or compliance requirement, you have a forcing function.

3. Compliance pressure

HIPAA + HITECH (US), PHIPA / PIPEDA (Canada), GDPR (EU patients). BAAs that constrain where data flows and who touches it. State-level laws that add regional rules. None of these are fundamentally incompatible with CPaaS, but the chain of custody is harder to audit when you're not operating the infrastructure yourself.

Capacity planning, in concrete terms

Healthcare RTC traffic is bursty. Plan for peak, not average.

DEV Community: ecosmob