Realtime Ui Websockets And Sse
Use When
- Live dashboards, notifications, or collaboration features
- Users expect near-real-time updates
Workflow
- Choose transport by directionality and browser support
- Define reconnect, heartbeat, and backoff policy
- Implement server-side fan-out and rate limits
- Handle stale state and conflict resolution rules
- Load test connection churn and burst traffic
Required Checks
- Reconnect behavior is deterministic
- Auth validated on connection and messages
- Backpressure prevents memory exhaustion
- Degraded mode exists when realtime path fails
Decision Framework
- Prefer SSE for server-to-client streams when bidirectional not required
- Use WebSockets when low-latency bidirectional needed
- Avoid unbounded in-memory fan-out per instance
- Provide polling fallback for critical data
Common Rationalizations And Rebuttals
- "Realtime can be added without server changes." -> Connection auth and scale need backend design.
- "No heartbeat needed." -> Dead connections accumulate silently.
- "Broadcast everything to all users." -> Privacy and cost issues follow.
Evidence Pack
- Reconnect storm test results
- Auth failure test evidence
- Latency and drop-rate metrics under load
- Fallback UX validation notes
Exit Criteria
- Realtime features remain usable under network instability
- Operational limits and alerts are defined
