SysPadExamples › Chat system

Chat system

An NLB (not ALB - connections are long-lived and stateful) fronts WebSocket chat servers, with a Redis presence tracker, a Cassandra-style message store, and push notifications for offline users.

Why chat needs an L4 load balancer, and message persistence kept separate from presence tracking so a message send both durably stores and routes in one hop.

Client Users DNS Route 53 NLB NLB Chat Servers API Gateway Presence ElastiCache Message Store Keyspaces Group Management Lambda Offline Push SNS AT LIMIT

How it works

NLB
An L4 network load balancer, not an L7 ALB: chat connections are long-lived, stateful WebSockets, so you balance connections once at connect time rather than per request.
Chat Servers
Hold the WebSocket. On each message they persist it and check the recipient’s presence in parallel, delivering over an open socket if online or handing to push if not.
Presence
Who is online right now, updated by heartbeats. Kept separate from the message store because it is tiny, hot, and ephemeral - the opposite access pattern to durable messages.

Request flows

Send a message

  1. Client
  2. DNS
  3. NLB
  4. Chat Servers
  5. Message Store
  6. Presence
  7. Offline Push

Presence heartbeat

  1. Client
  2. DNS
  3. NLB
  4. Chat Servers
  5. Presence

Manage a group

  1. Client
  2. DNS
  3. NLB
  4. Chat Servers
  5. Group Management

Other interview practice

Open this architecture in SysPad · All examples