Real-Time APIs · Real-Time in Practice
Managed vs Self-Hosted Real-Time
Make a build-or-buy decision with real numbers.
Self-hosting WebSockets is easy for thousands of connections and hard for millions across regions: you need gateways, pub/sub, presence, history, auth integration, draining, monitoring and on-call. Managed services charge per connection-minute and message but provide global edges, SDKs with reconnection/history, and SLAs. Estimate: peak concurrent connections, messages/day, fan-out ratio, latency targets and team capacity.
Build vs buy
| Factor | Self-hosted | Managed |
|---|---|---|
| Cost at small scale | Low | Low–medium |
| Cost at huge scale | Infra + team | Can be high (per message) |
| Time to market | Weeks–months | Days |
| Features (presence, history, SDKs) | Build | Included |
| Control / data residency | Full | Vendor-dependent |
| On-call burden | Yours | Shared |
Back-of-the-envelope
200k peak connections × 30 days × 24 h × 60 min ≈ 8.6 billion connection-minutes/month
50 messages/user/day × 1M users × fan-out 5 = 250M deliveries/day
Compare: vendor pricing for these volumes vs gateway fleet + Redis/NATS + 1–2 engineers' time
Common pitfalls
- Choosing by sticker price without team cost.
- No abstraction layer, making migration impossible.
- Ignoring data residency/compliance requirements.
Key points
- Estimate connections, messages, fan-out
- Include team and on-call cost
- Abstract the provider
Further reading: AWS AppSync (managed real-time GraphQL)
Practice questions
Which numbers drive the real-time build-vs-buy decision?
Answer
Peak concurrent connections, message volume and fan-out, latency/geography requirements, and the engineering/on-call capacity to operate your own infrastructure.
Why put an abstraction layer over a managed real-time vendor?
Answer
To limit lock-in: application code depends on your publish/subscribe interface, so switching vendors or self-hosting later is feasible.
Open in the app to mark lessons complete, take notes and track your progress.