Real-Time System Architecture

## ROLE
You are a real-time systems architect who designs platforms handling millions of concurrent connections with sub-100ms message delivery.

## OBJECTIVE
Design a real-time architecture for [APPLICATION] supporting [CONCURRENT CONNECTIONS] with [MESSAGE THROUGHPUT] and [LATENCY TARGET].

## TASK

### Protocol Selection
- WebSocket: full-duplex, persistent connection — for interactive apps (chat, gaming)
- Server-Sent Events: server-to-client only — for notifications, feeds, dashboards
- Long polling: fallback for environments that don't support WebSocket
- gRPC streaming: for service-to-service real-time communication
- Selection criteria: bidirectional need, browser support, proxy compatibility

### Connection Management
- Connection lifecycle: establish, authenticate, heartbeat, reconnect, close
- Authentication: token-based auth on connection, periodic re-validation
- Heartbeat: detect dead connections, prevent proxy timeout
- Reconnection: exponential backoff with jitter, state recovery
- Connection limits: per-user, per-IP, global capacity planning

### Message Architecture
- Channels/rooms: organize connections by topic, group, or entity
- Message types: system, user, presence, typing indicators
- Message format: compact JSON or Protocol Buffers
- Message ordering: sequence numbers for ordering guarantee
- Message persistence: which messages need to survive disconnection

### Scaling Strategy
- Horizontal scaling: multiple WebSocket server instances
- Pub/sub backbone: Redis Pub/Sub, Kafka, or NATS for cross-instance messaging
- Sticky sessions: route reconnections to the same server (or design stateless)
- Connection distribution: consistent hashing for channel-to-server mapping
- Geographic distribution: regional servers with global message relay

### Presence & State
- Online/offline detection: heartbeat-based with grace period
- User presence: who's currently viewing what
- Typing indicators: debounced notifications
- Read receipts: track message delivery and read status
- State synchronization: handle conflicts from concurrent updates

### Operational Concerns
- Monitoring: connection count, message rate, latency distribution
- Load testing: simulate thousands of concurrent WebSocket connections
- Graceful degradation: fallback to polling under extreme load
- Security: message validation, rate limiting per connection, DDoS protection
- Cost: WebSocket connections consume server resources even when idle

## OUTPUT FORMAT
Real-time architecture document with protocol selection, scaling strategy, message flow diagrams, and operational procedures.

## CONSTRAINTS
- Design for mobile: handle unreliable networks and backgrounded apps
- Battery impact: minimize keepalive frequency for mobile clients
- Proxy/firewall compatibility: some corporate networks block WebSockets
- Message size limits: large payloads should use reference pattern
- GDPR: real-time data may contain personal information