Problem Statement: The NAT Wall and the Hybrid Answer
Frames hybrid P2P chat as a transport-economics and reliability problem, not a protocol trivia question.
Problem statement
Design a chat platform where two clients first attempt a direct peer-to-peer connection for messages and media, and fall back seamlessly to a cloud relay when direct connectivity fails. The product must deliver 1:1 text, media, and optional voice/video, preserve end-to-end encryption where required, keep delivery semantics (sent, delivered, read), support multi-device sessions, and operate at global scale.
The defining constraint is the NAT wall. A large fraction of clients sit behind consumer NATs, carrier-grade NAT (CGNAT), or restrictive enterprise firewalls. WebRTC field data cited across implementations puts symmetric NATs at roughly 10-15% of endpoints, and industry practitioners commonly quote 10-20% of attempted peer connections requiring TURN-style relay assistance. Symmetric NAT to symmetric NAT pairs fail direct connectivity almost always. Therefore a design that assumes P2P works is wrong, and a design that always relays pays an avoidable bandwidth bill.
Why hybrid is the economically correct answer
Relay bandwidth is the single largest variable cost in real-time communication. WhatsApp publicly states it delivers roughly 100 billion messages per day to about 2 billion monthly users; even at a modest 200 bytes per encrypted payload, fully relaying text alone would push multi-terabyte-per-day egress. Media is worse: a single 720p video call consumes 0.5-2.5 Mbps per direction. If direct paths absorb 60-80% of media minutes, relay infrastructure shrinks by a factor of 3-5x. That is the entire business case for hybrid in one sentence: P2P converts user connectivity into free transport capacity, and the cloud absorbs the residual that physics and firewalls refuse.
The four planes
- Signaling plane: identity, session negotiation, SDP or capability exchange, ICE candidate delivery, multi-device fanout. Always through the cloud; never P2P for bootstrap.
- Transport plane: ICE state machine, STUN checks, TURN allocation, QUIC or WebRTC data channels, connection migration.
- Messaging plane: ordering, deduplication, acknowledgements, offline queues, media chunk transfer, delivery receipts.
- Governance plane: auth, key distribution, rate limiting, abuse controls, relay load management, observability of direct-vs-relay mix.
A strong answer keeps these planes separate. Signaling must stay strongly available even when media is P2P. Transport selection is a per-session decision with continuous re-evaluation. Messaging semantics must be identical regardless of path, or users will see path-dependent behavior and file bugs.
Explicitly out of scope
Group calls with more than 4 participants (they need an SFU, a different architecture), PSTN telephony bridging, content delivery for broadcast channels, and building our own congestion-control algorithm from scratch. We design the interfaces to these dependencies, not their internals.
Key Highlights
- •Roughly 10-20% of peer pairs need relay assistance; symmetric NAT pairs almost never connect directly.
- •Relay bandwidth is the dominant variable cost; direct paths absorb 60-80% of media minutes in a healthy hybrid fleet.
- •Signaling always flows through the cloud; only media and bulk data attempt the direct path.
- •Four planes: signaling, transport, messaging, governance. Path choice must not change message semantics.
- •WhatsApp's ~100B messages/day at ~2B MAU shows why full relay of even text is economically brutal.
Section Rescue Kit
Buzzwords to use:
Safe statements:
- "Let me separate what must go through the cloud from what may go direct, because that boundary defines the whole architecture."
- "Before choosing protocols, I want to establish the failure budget: how often may direct attempts fail before we prefer relay-first?"