Real-Time Everything Syndrome
Product teams demand real-time updates for everything — live dashboards, instant notifications, real-time collaboration, streaming analytics. The assumption is that users expect real-time and anything less feels broken. So engineering teams build WebSocket connections, event streaming pipelines, and push notification systems for features where polling every 30 seconds would be indistinguishable to users. The infrastructure cost of real-time is 5-10x higher than batch or polling. Connection management at scale is a distributed systems problem. Every real-time feature adds persistent connections that consume server resources even when idle. The result: massive infrastructure spend for features where users wouldn't notice a 30-second delay, and engineering complexity that slows down every subsequent feature.
What people believe
“Users expect real-time updates and anything less feels broken.”
| Metric | Before | After | Delta |
|---|---|---|---|
| Infrastructure cost | Polling baseline | 5-10x for real-time | +700% |
| Feature development time | Baseline | +40-60% for real-time features | +50% |
| User-perceived improvement | 30s polling | Instant updates | Minimal for most features |
| System complexity | Request-response | Bidirectional streaming | +300% |
Don't If
- •Your users wouldn't notice a 30-second delay in the data you're making real-time
- •You don't have the engineering capacity to maintain real-time infrastructure
If You Must
- 1.Measure whether users actually benefit from real-time before building it
- 2.Use Server-Sent Events instead of WebSockets for one-directional updates
- 3.Implement graceful degradation to polling when real-time connections fail
- 4.Set connection idle timeouts to reclaim server resources
Alternatives
- Smart polling — Poll at intervals appropriate to the data freshness requirement
- Optimistic UI — Show instant local updates while syncing in background
- Selective real-time — Real-time only for features where latency matters (chat, collaboration)
This analysis is wrong if:
- Users consistently prefer and engage more with real-time features compared to 30-second polling equivalents
- Real-time infrastructure costs scale linearly with users rather than superlinearly
- Engineering teams maintain real-time features with the same velocity as polling-based features
- 1.Slack Engineering: Scaling WebSockets
Slack's challenges maintaining millions of persistent WebSocket connections
- 2.Discord Engineering: Real-Time at Scale
Infrastructure costs and complexity of maintaining real-time for millions of concurrent users
- 3.Nielsen Norman Group: Response Time Limits
Research showing users perceive delays under 1 second as instantaneous
- 4.Figma Engineering: Multiplayer Infrastructure
The significant engineering investment required for real-time collaboration
This is a mirror — it shows what's already true.
Want to surface the hidden consequences of your engineering decisions?