Concevoir un système de discussion en temps réel
Parcourez l’architecture d’un système de discussion en temps réel, en abordant les connexions, la distribution des messages, le stockage et la mise à l’échelle.
Concevoir un système de discussion en temps réel est une leçon System Design Basics for Backend Developers gratuite sur CoddyKit. Ceci est la leçon 4 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage System Design Basics for Backend Developers, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours System Design Basics for Backend Developers comprend 4 leçons au total.
Certaines parties de cette leçon n'ont pas encore été traduites et s'affichent en anglais.
The Problem
Design a chat system like WhatsApp or Slack: users send messages that appear on recipients' devices instantly, with history, online presence, and delivery receipts — at the scale of millions of concurrent users.
Requirements
Clarify scope first:
- Functional: 1:1 and group chat, message history, presence, delivery/read receipts
- Non-functional: low latency, high availability, ordered delivery, horizontal scale
Why Not Plain HTTP?
Classic HTTP is request-response — the server cannot push. Polling wastes resources and adds latency. Real-time chat needs a persistent, bidirectional connection.
WebSockets
WebSockets upgrade an HTTP connection into a long-lived, full-duplex channel. The server can push a message the instant it arrives. This is the backbone of real-time chat.
GET /chat HTTP/1.1
Upgrade: websocket
Connection: Upgrade
# After upgrade: server can push frames anytimeConnection Servers
A fleet of connection servers holds the open WebSockets. Since a sender and recipient may be connected to different servers, you need a way to route a message from one server to another.
Routing Between Servers
A presence/session store (e.g. Redis) maps each user to the connection server holding their socket. A message broker or pub/sub forwards messages to the right server so it can push to the recipient.
user_to_server = {
'alice': 'conn-3',
'bob': 'conn-7'
}
# alice -> bob: route message to conn-7Storing Messages
Chat is write-heavy with huge volume. A wide-column store like Cassandra suits it: partition by conversation id, cluster by timestamp, so fetching recent history in order is fast.
PRIMARY KEY ((conversation_id), message_ts)
WITH CLUSTERING ORDER BY (message_ts DESC)Delivery Guarantees
Use a per-user inbox queue and acknowledgements. Mark messages sent, delivered, and read. If a recipient is offline, queue the message and deliver when they reconnect; retries plus message IDs keep it idempotent.
Ordering
Messages must appear in a consistent order. Attach a monotonic sequence or timestamp per conversation. Clients sort by it, so even out-of-order network delivery is corrected on display.
import time
base = int(time.time() * 1000)
seq = [base, base + 1, base + 2]
print('ordered message ids:', seq)Group Chat at Scale
Group messages fan out to every member. For small groups, push directly; for large ones, write once to the conversation and let members pull, or fan out asynchronously via the broker to avoid a write storm.
Putting It Together
The full picture: clients hold WebSockets to connection servers, a presence store routes via pub/sub, messages persist in a wide-column store, and queues plus receipts handle offline delivery and ordering. Each piece scales horizontally.
Quick Check
Test your understanding of real-time chat design.
Recap
You designed a real-time chat system:
- WebSockets give persistent bidirectional connections
- A presence store plus pub/sub routes messages between connection servers
- A wide-column store holds ordered history
- Queues and receipts handle offline delivery; ordering uses per-conversation sequences
Questions Fréquemment Posées
La leçon « Concevoir un système de discussion en temps réel » est-elle gratuite ?
Oui — le texte complet de « Concevoir un système de discussion en temps réel » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours System Design Basics for Backend Developers, passe à CoddyKit PRO. Le cours System Design Basics for Backend Developers comprend 4 leçons au total.
Qu'est-ce que j'apprendrai dans « Concevoir un système de discussion en temps réel » ?
Parcourez l’architecture d’un système de discussion en temps réel, en abordant les connexions, la distribution des messages, le stockage et la mise à l’échelle. Tu pratiques System Design Basics for Backend Developers avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.
Dois-je avoir de l'expérience pour commencer System Design Basics for Backend Developers ?
Aucune expérience préalable n'est requise. System Design Basics for Backend Developers sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 4 sur 4.
Combien de temps prend la leçon « Concevoir un système de discussion en temps réel » ?
La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.
Peux-tu écrire et exécuter du code dans cette leçon System Design Basics for Backend Developers ?
Oui. Chaque leçon System Design Basics for Backend Developers inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.
Toutes les leçons de ce cours
- Conception d’un raccourcisseur d’URL
- Création d’un fil d’actualité pour les réseaux sociaux
- Mise à l’échelle d’une plateforme de commerce en ligne
- Concevoir un système de discussion en temps réel