Push Mechanisms

Client                              Server
  │                                    │
  │── GET /updates?since=100 ─────────→│
  │                                    │ (holds request open...)
  │                                    │ (waiting for new data...)
  │                                    │ (30 seconds pass, no data)
  │←── 204 No Content (timeout) ───────│
  │                                    │
  │── GET /updates?since=100 ─────────→│
  │                                    │ (holds request open...)
  │                                    │ (new message arrives!)
  │←── 200 {messages: [...]} ──────────│
  │                                    │
  │── GET /updates?since=105 ─────────→│  (immediately reconnects)
  │                                    │ (waiting again...)

Timeline:
  T=0s:   Client sends request
  T=0-30s: Server holds connection (no data yet)
  T=12s:  New data arrives → server responds immediately
  T=12s:  Client processes data, sends new request
  → Effective latency: 0-30 seconds (depends on when data arrives)

1. HANDSHAKE (HTTP → WebSocket upgrade):
   Client → GET /chat HTTP/1.1
            Upgrade: websocket
            Connection: Upgrade
   Server → HTTP/1.1 101 Switching Protocols
            Upgrade: websocket

2. PERSISTENT CONNECTION (full-duplex):
   Client ──→ "Hello!"           ──→ Server
   Client ←── "Hi there!"        ←── Server
   Client ──→ "How are you?"     ──→ Server
   Server ──→ "New notification" ──→ Client  (server-initiated!)
   
   → No HTTP headers per message (~2-6 bytes framing vs ~800 bytes HTTP)
   → Either side sends anytime (no request-response pattern)
   → Connection stays open for minutes, hours, or days

3. CLOSE:
   Either side sends a close frame → clean shutdown

Problem: 1M connected users across 100 servers.
  User A (Server 1) sends a message to User B (Server 47).
  Server 1 doesn't know about User B's connection.

Solution: Redis Pub/Sub (or Kafka)
  1. User A sends message → Server 1
  2. Server 1 publishes to Redis channel "chat:room:42"
  3. ALL servers subscribed to "chat:room:42" receive the message
  4. Server 47 finds User B's connection → pushes the message

  Server 1 ──→ Redis Pub/Sub ──→ Server 47 ──→ User B
  
  Every server subscribes to channels for its connected users.
  Redis broadcasts to all subscribers.
  This is how Slack, Discord, and every large chat system works.

Client opens connection:
  GET /events HTTP/1.1
  Accept: text/event-stream

Server responds with streaming headers:
  HTTP/1.1 200 OK
  Content-Type: text/event-stream
  Cache-Control: no-cache
  Connection: keep-alive

Server pushes events as they happen:
  data: {"type": "notification", "message": "New follower!"}

  data: {"type": "price_update", "symbol": "AAPL", "price": 178.50}

  data: {"type": "notification", "message": "Your order shipped!"}

  (connection stays open, server sends more events...)

Client-side (JavaScript):
  const source = new EventSource('/events');
  source.onmessage = (event) => {
    const data = JSON.parse(event.data);
    // Update UI with new data
  };
  // Auto-reconnects if connection drops!

1. REGISTRATION:
   App starts → registers with APNs/FCM → gets a device token
   App sends device token to your backend
   Backend stores: user_id → device_token

2. SENDING:
   Event occurs (new message, order shipped, price alert)
   Backend → APNs/FCM API: "Send to device_token: 'Your order shipped!'"
   APNs/FCM → Device: notification appears in system tray

3. DELIVERY:
   Device online → notification delivered immediately (~1-5 seconds)
   Device offline → APNs/FCM queues it, delivers when device reconnects
   App closed → notification still appears (OS-level delivery)

Flow:
  Your Server → APNs (iOS) / FCM (Android) → User's Device
                    ↑
            Third-party service handles delivery,
            queuing, and device management

User online (app open):
  Client ⇄ WebSocket ⇄ Server ⇄ Redis Pub/Sub ⇄ Other Servers
  → Live messages, typing, presence (sub-50ms)

User offline (app closed):
  Server → FCM/APNs → Device notification
  → "Alice sent you a message" (1-5 seconds)

Admin dashboard:
  Browser ← SSE ← Server
  → Live metrics stream (1 update/sec)

Fallback (WebSocket blocked):
  Client → Long Polling → Server
  → Messages delivered with ~1-2s latency

Connection management:
  10M users × 100 servers = 100K connections per server
  Redis Pub/Sub for cross-server message routing
  Presence service tracks who's online (Redis SET)

Need bidirectional communication?
  ├── YES → WebSockets (chat, gaming, collaboration)
  └── NO ↓

Need to reach users when app is closed?
  ├── YES → Push Notifications (alerts, re-engagement)
  └── NO ↓

Need server → client streaming?
  ├── YES → SSE (notifications, feeds, live metrics)
  └── NO ↓

Need near-real-time with HTTP compatibility?
  ├── YES → Long Polling (fallback, restricted networks)
  └── NO → Regular HTTP polling is fine