ГАЙД НА SYSTEM DESIGN

System Design Guide (Messenger like Telegram) — Key Concepts & Architecture Features

Interview mindset / how to “win” system design

• Interviews typically start with: design a basic messenger (Telegram-like).
• Be confident and authoritative in your reasoning.
• Draw full architecture and justify how it works under extreme scenarios (e.g., high load).
• Use structured answers in this order: requirements → entities → services → API → scalability → reliability.

---

Core Requirements / User-Facing Features

Dialog & message functionality

• List of dialogs
• Create dialogs
• List messages per dialog
• Real-time sending/receiving
• Mark messages as read

Offline behavior

• If the recipient is not online, send a push notification.

---

Key Data Model / Entities

Extracting entities from requirements

• Users
• Dialogs
• Messages
• Push notifications

Roles

• Users and Admins
  • Interview focus is suggested to be more on user flow.

---

API Design Approach

REST-style API (user side)

• Register
• Profile retrieval
• Authorization

Messaging responsibilities (user/messaging services)

• Dialog list / create
• Message list per dialog
• Send messages
• Mark messages as read

Scaling via load estimation

• Compute requests per second (RPS) from assumptions/asked metrics:
  • active users/day
  • average messages per user
• For a messenger:
  • Write load is highest for sending messages
  • Read load is highest for reading messages
• Include seasonality (e.g., “holidays double RPS”).

---

Real-Time Messaging: Polling vs WebSockets

Polling (“pulse”)

• Client asks every second: “any new messages?”
• Downsides:
  • wastes client battery
  • increases server request load

WebSockets

• Establish a persistent, bidirectional connection after login.
• If user is offline, fall back to push notifications.

Important rationale

• Not everything should be switched to WebSockets.
• Mixing real-time delivery with historical retrieval can cause message ordering issues (e.g., new messages appear out of order while scrolling).
• Therefore, historical retrieval should remain separate from real-time delivery.

---

System Infrastructure Pattern (Cloud, LB, Gateway)

Deployment pattern

• External load balancer → API gateway → internal services
• Multiple service instances for reliability/throughput
• Internal load balancing (commonly mentioned in Kubernetes)

API Gateway (aka “API Gway / API Gateway”)

• Single entry point for internal services
• Handles:
  • routing requests to the correct service
  • token/cookie validation (authentication)
• Gateway itself has instances + a load balancer in front.

---

Notification Service Design (Push + Asynchronous Queue)

Push notifications flow (Android-centric)

1. User logs in and is asked for notification permission
2. App obtains an FSM token (described as a Firebase Cloud Messaging token)
3. Store mapping: device ↔ token (1 device = 1 token)
4. Notification service sends to the mobile provider using those tokens

Scaling problem

• During spikes (e.g., holidays), direct synchronous calls can fail due to:
  • provider/service overwhelm
  • delivery delays causing high message latency

Solution: queue + async processing

• Messaging service acts as a producer:
  • writes events to a queue when notification is needed
  • returns without waiting
• Notification service acts as a processor:
  • reads queue events at its own pace and sends to FSM
• Key emphasis:
  • control queue size
  • avoid excessive lag
• Queue decoupling is presented as a reusable pattern.

---

Database Choices & Scaling Concepts (Inspired by Discord)

Why DB matters for read/write performance

• Example claim: Discord changed storage approaches due to latency stability issues.

NoSQL / wide-column approach

• SQL DBs: good querying but harder scaling
• Wide-column / “Syla DB” (described similarly to Cassandra/Scylla):
  • sacrifices some SQL features (joins/complex transactions)
  • gains predictable speed

Partitioning

• Use a partition key so related data stays on the same node.
• Example: group messages by dialog ID so dialog reads hit fewer nodes.

Replication

• Store copies across nodes to tolerate failures.

Time-window bucket strategy for message storage

• Partition key idea: (channel/dialog ID + time bucket)
• Bucket increases every ~10 days to prevent partitions from growing unbounded.
• The scheme is described as selected based on production experience.

---

Online Real-Time Delivery at Scale (WhatsApp-like idea)

WebSocket gateway tier

• A WebSocket gateway manages persistent connections.
• Many users → multiple gateway instances.

Session registry (Redis-like fast store)

• Stores mappings:
  • user → gateway/address/online status
• If connection times out or user goes offline, the entry is removed.

Delivery logic

• Client sends via websocket gateway
• Messaging:
  • writes to queue
  • asks gateway to deliver in real time if recipient is online
• If offline:
  • enqueue for push notifications

---

End-to-End Message Flow (Final “correct” design)

When sending a message

1. Client connects to WebSocket gateway (stateful, long-lived)
2. Client sends message over websocket
3. Messaging/dialog service writes the message to a queue
4. Messaging/dialog service persists the message in DB
5. Messaging/dialog service calls the WebSocket gateway to deliver in real time
6. If recipient is offline, enqueue an event for push notifications
7. Notification service processes queue events and sends push via FSM token(s)

Routing to the right WebSocket gateway instance

• Gateway service uses the session registry/lookup to find the recipient’s active connection and deliver to the correct instance.

---

Main speakers/sources (as presented)

• Primary source: Video narrator/host (no specific name given in subtitles)
• Secondary referenced materials/companies:
  • Alex Xu (book mention)
  • Discord
  • WhatsApp
  • Yandex lead (course reference)
  • Google/Firebase Cloud Messaging (FSM token)