Interview OS
Back to System Design

System Design

Chat system

Senior level · full staged walkthrough

Senior

Architecture

Senior
ClientGatewayRoutingState & deliveryWSpublishdeliverofflineClientWebSocketWS GatewayPub/SubKafkaFan-outMessage storeby convoPresenceRedisPush notif
ClientEdgeAsyncServiceData

Solution, step by step

  1. 1

    Functional requirements

    • 1:1 and group messaging
    • Delivery + read receipts
    • Online presence
    • History sync across devices
  2. 2

    Non-functional requirements

    • Message delivery latency < 200ms
    • Ordered delivery within a conversation
    • At-least-once delivery + dedup
    • High availability; durable message history
  3. 3

    Capacity & estimation

    • 50M DAU, ~40 msgs/user/day → ~2B msgs/day ≈ 23K msgs/s avg, ~100K/s peak
    • Avg message ~1 KB → ~2 TB/day raw
    • Millions of concurrent WebSocket connections → many gateway nodes
    • Presence fan-out grows with group size
  4. 4

    Preliminary design

    • Persistent WebSocket per client to a gateway
    • Publish messages to a queue, fan out to recipients
    • Append messages to a per-conversation store
  5. 5

    Final architecture

    • WebSocket gateways (stateful connections) behind an L4 LB; sticky sessions
    • Pub/sub (Kafka) for message routing; consumer groups per gateway
    • Message store partitioned by conversation_id, sorted by sequence number
    • Presence service backed by Redis with TTL heartbeats
    • Push-notification service for offline recipients; outbox for reliability

Interview Q&A (9)

Each client holds a persistent WebSocket to a stateful gateway node behind an L4 load balancer with sticky sessions, so messages can be pushed instantly.

Key components

  • WS gateway
  • Presence service
  • Message store
  • Push notification service
  • Pub/sub

Bottlenecks & how to address them

  • Large-group fan-out → fan-out-on-read for big groups
  • Connection storms on reconnect → backoff + jitter
  • Hot conversations → partition + shard

Tradeoffs to articulate

  • Fan-out on write vs read for large groups
  • Ordering guarantees vs latency
  • At-least-once vs exactly-once delivery

Where this content comes from

For full transparency, this content is curated and verified from these sources:

Published architecture case studiesCompany engineering blogsOppZen design rubric library