تصميم نظام مراسلة فورية عالي التوسع مثل واتساب
معمارية بوابات الاتصال الدائم عبر WebSockets، توجيه الرسائل المؤقتة، سجل الجلسات في Redis، وطوابير الانتظار عند انقطاع الاتصال.
📱 WhatsApp — How a Real-Time Messaging System Works
سؤال انترفيو:
واتساب شغال إزاي فعليًا؟الإجابة مش:
Send Message()وخلاص.
أنت بتتكلم عن Real-Time Networking + Durable Delivery + End-to-End Encryption + Multi-Device + Queues + Presence + Massive Scale.
📚 المحتويات
- يعني إيه Real-Time؟
- Polling vs Persistent Connections
- TCP و WebSocket
- هل WhatsApp يستخدم WebSocket؟
- XMPP و FunXMPP
- Erlang
- رحلة الرسالة
- Message Lifecycle
- Offline Delivery
- Idempotency
- Message Ordering
- Multi-Device
- End-to-End Encryption
- Signal Protocol
- Forward Secrecy
- Groups و Sender Keys
- Presence و Typing
- Media
- Backup
- Scaling
- أهم مشاكل System Design
- إجابة انترفيو جاهزة
- ملاحظات وتصحيحات مهمة
- مصادر رسمية
🎯 يعني إيه Real-Time؟
لما يحصل Event عند User:
New Message
Typing
Online
Delivered
Read
ويظهر تأثيره عند User آخر بسرعة كافية ليشعر المستخدم أن النظام لحظي.
المشكلة إن:
Real-Time
لا تعني بالضرورة:
Zero Latency
لكن تعني أن التصميم يقلل التأخير قدر الإمكان ويجعل الاتصال/التسليم مناسبًا لطبيعة الـ workload.
🔄 Polling vs Persistent Connections
أسهل حل:
Client
↓
GET /messages
↓
No new messages
بعد ثانيتين
GET /messages
↓
No new messages
بعد ثانيتين
GET /messages
↓
New message
ده:
Polling
وهو بسيط، لكنه غير مثالي لتطبيق مراسلة ضخم لأن أغلب الطلبات قد لا تنتج عنها بيانات جديدة.
بدائل أكثر ملاءمة للـ real-time:
WebSocket
Long Polling
Server-Sent Events
Custom persistent protocols
Push notifications
حسب المنصة وطبيعة الاتصال.
🌐 TCP و Persistent Connections
TCP يوفر اتصالًا موثوقًا ومرتبًا بين الطرفين.
عند إنشاء الاتصال توجد عملية:
SYN
↓
SYN-ACK
↓
ACK
ثم يمكن نقل البيانات عبر الاتصال.
لكن مهم جدًا:
HTTP ليس معناه بالضرورة أن TCP يتقفل بعد كل Request.
HTTP/1.1 يدعم persistent connections، وHTTP/2 وHTTP/3 لديهم نماذج مختلفة تمامًا لإدارة الاتصالات.
فالجملة الأدق:
HTTP request/response
≠
ضرورة فتح TCP جديد لكل Request
🔌 WebSocket
WebSocket يوفر قناة:
Full Duplex
فبعد إنشاء الاتصال، يستطيع:
Client → Server
Server → Client
إرسال البيانات بدون نمط request/response التقليدي لكل Event.
في الويب، يبدأ WebSocket عادةً من HTTP ثم يحصل Upgrade إلى WebSocket.
❓ هل WhatsApp يستخدم WebSocket؟
هنا لازم نفرق بين:
Generic Web Real-Time Architecture
و:
WhatsApp's proprietary mobile protocol
WhatsApp ليس مجرد WebSocket application.
WhatsApp نشر أن clients يتصلون ببنيته باستخدام بروتوكول مبني على:
XMPP
وفي multi-device architecture لديه client/server architecture خاصة به. citeturn0search6turn0search0
لذلك الأفضل في الانترفيو أن تقول:
"WebSocket حل شائع للـ web real-time، لكن WhatsApp لديه بروتوكول وclient/server architecture خاصة به، وقد استخدم XMPP كأساس تاريخي/بروتوكولي."
بدل:
"WhatsApp = WebSocket."
📦 XMPP و FunXMPP
XMPP:
Extensible Messaging and Presence Protocol
وهو بروتوكول مفتوح للمراسلة والـ presence.
تاريخيًا، WhatsApp بنى جزءًا من messaging infrastructure على XMPP، وذكر Meta أن third-party clients تتصل ببنية WhatsApp باستخدام protocol مبني على XMPP. citeturn0search6
كما أن WhatsApp كان لديه implementation optimized/customized من XMPP عُرفت باسم:
FunXMPP
لكن لازم نفرق:
لا تفترض أن كل تفاصيل البروتوكول الحالي أو transport الداخلي منشورة للعامة.
بعض التفاصيل implementation-specific.
⚙️ Erlang
Erlang صُممت أصلًا للأنظمة التي تحتاج:
Concurrency
Fault Tolerance
Distributed Systems
High Availability
وده مناسب جدًا لطبيعة messaging systems.
Meta وثقت تاريخيًا استخدام Erlang في أنظمة chat، وذكرت أن نموذج Erlang للـ lightweight processes كان مناسبًا لملايين المستخدمين المتزامنين. citeturn1search19
لكن تجنب في الانترفيو أرقامًا مطلقة مثل:
Every Erlang process = exactly 300 bytes
One server = exactly 2 million WhatsApp connections
إلا لو عندك مصدر محدد لنفس النسخة والـ workload.
الأرقام القديمة لا تعني بالضرورة architecture الحالية.
🧠 Fault Tolerance
من أشهر أفكار Erlang/OTP:
Supervision
الفكرة:
Worker
↓
Crash
↓
Supervisor
↓
Restart / Recover
وده جزء من فلسفة:
Let It Crash
لكن معناها مش:
"سيب البرنامج يقع."
المقصود:
صمم الـ processes بحيث تكون failures isolated ويمكن للـ supervisors إعادة تشغيل الأجزاء الفاشلة بدل انهيار النظام كله.
📨 رحلة رسالة واحدة
خلينا نفترض:
Ahmed → Mohamed
"السلام عليكم"
رحلة الرسالة ممكن تتصور بشكل مبسط:
Ahmed Device
↓
Encrypt
↓
Authenticated Connection
↓
WhatsApp Infrastructure
↓
Durable / Delivery State
↓
Recipient Device(s)
↓
Decrypt
↓
Display
وفي multi-device تصبح الصورة أعقد:
Ahmed Device
↓
Encrypted fan-out
├────────→ Ahmed Laptop
├────────→ Mohamed Phone
└────────→ Mohamed Laptop
Meta توضح أن WhatsApp multi-device يستخدم client-fanout: الرسالة تُشفّر بشكل منفصل لكل جهاز مستهدف عبر pairwise encrypted sessions. citeturn0search0
🆔 Message ID
كل رسالة تحتاج identifier فريد مثل:
messageId
ليه؟
لأن الشبكات غير موثوقة 100%.
مثلاً:
Client → Server
السيرفر حفظ الرسالة.
لكن response ضاع.
الـ client يعتقد أن العملية فشلت.
فيعيد الإرسال.
بدون idempotency:
Message A
Message A
قد تصل مرتين.
مع:
messageId = msg_123
السيرفر يستطيع اكتشاف التكرار والتعامل معه بأمان.
♻️ Idempotency
الفكرة:
إعادة نفس العملية لا يجب أن تنتج تأثيرًا مكررًا.
مثال:
msg_123
وصل أول مرة:
INSERT
وصل مرة ثانية:
Already exists
→ return existing state
وده مهم جدًا في:
Messaging
Payments
Orders
Notifications
Uploads
💾 Persist Before Delivery
في نظام موثوق، من الخطير أن يكون المسار:
Receive
↓
Send to recipient
↓
Save
لو السيرفر وقع بين المرحلتين قد تفقد الرسالة أو حالة التسليم.
التصميم الأكثر أمانًا يكون أقرب إلى:
Receive
↓
Persist durable state
↓
Attempt delivery
↓
Update delivery state
وده نفس مبدأ:
Store and Forward
لكن لازم نكون دقيقين:
WhatsApp لا يعني أن السيرفر يحتفظ بتاريخ المحادثة كاملًا للأبد.
Meta تذكر صراحة في وصف multi-device أن الرسائل لا تُخزن على السيرفر بعد تسليمها في ذلك النموذج، بينما الرسائل غير المسلّمة تحتاج آلية تسليم مؤقتة. citeturn0search0
📬 Offline Delivery
لو Mohamed Offline:
Ahmed
↓
WhatsApp Infrastructure
↓
Pending delivery
عندما يعود جهاز Mohamed للاتصال:
Mohamed Device
↓
Reconnect
↓
Retrieve pending messages
لكن لا تجعل رقم:
30 days
جزءًا من الـ architecture كأنه contract ثابت حاليًا إلا إذا كنت تشير إلى مصدر رسمي محدد ومحدث.
الفكرة الأهم في الانترفيو:
Undelivered messages تحتاج durable temporary storage/retry semantics، بينما الرسائل التي تم تسليمها ليست بالضرورة محفوظة كأرشيف دائم على WhatsApp servers.
✓ Message Lifecycle
الـ UI ممكن يعرض حالات مثل:
Sending
↓
Sent
↓
Delivered
↓
Read
لكن لا تفترض أن العلامات هي مجرد UI state.
هي تعكس events/acknowledgements مختلفة في delivery lifecycle.
مثلاً:
Sent
لا تعني:
الطرف الآخر قرأ الرسالة.
و:
Delivered
لا تعني:
الطرف الآخر فتح المحادثة.
🔢 Message Ordering
افترض:
1
2
3
4
5
وفي نظام distributed:
1 → Server A
2 → Server B
3 → Server A
مع:
Retries
Queues
Multiple Devices
Network delays
لا يجب أن تفترض أن arrival order دائمًا يساوي logical order.
ممكن تستخدم:
Sequence Numbers
Server-assigned ordering
Conversation sequence
Logical timestamps
Sync state
والحل الفعلي يعتمد على protocol والـ consistency requirements.
📱 Multi-Device
دي من أهم النقاط في WhatsApp الحديث.
قديمًا كان الهاتف الأساسي يمثل محورًا أساسيًا.
لكن WhatsApp multi-device غيّر النموذج.
Meta توضح أن كل companion device لديه:
Independent connection
Independent identity key
والأجهزة يمكنها العمل حتى بدون استمرار اتصال الهاتف الأساسي. citeturn0search0
🔐 Multi-Device Encryption
لو Ahmed لديه:
Phone
Laptop
وMohamed لديه:
Phone
Laptop
فالموضوع ليس:
Ahmed → Mohamed
فقط.
هناك أجهزة متعددة.
Meta تشرح أن WhatsApp يستخدم:
Client Fan-Out
والرسالة في one-to-one multi-device يتم تشفيرها بشكل منفصل لكل جهاز مستهدف باستخدام pairwise encrypted sessions. citeturn0search0
يعني بشكل مبسط:
Message
↓
Encrypt for Ahmed Laptop
Encrypt for Mohamed Phone
Encrypt for Mohamed Laptop
↓
Send
والسيرفر يقوم بالتوجيه والتسليم، وليس بقراءة النص نفسه.
🔐 End-to-End Encryption
WhatsApp يعتمد على:
End-to-End Encryption
المبدأ:
Sender Device
↓
Encrypt
↓
Server
↓
Encrypted message
↓
Receiver Device
↓
Decrypt
السيرفر يستطيع التعامل مع metadata اللازمة للتسليم والبنية التحتية، لكنه لا يفترض أن يكون قادرًا على قراءة محتوى الرسالة النصية المشفر بين الأطراف.
Meta تؤكد أن E2EE هي أساس الخصوصية في WhatsApp، وأن محتوى الرسائل لا يكون متاحًا لواتساب نفسه لفك تشفيره. citeturn0search11
🔑 Public / Private Keys
التشفير الحديث ليس مجرد:
Public Key + Private Key
وخلاص.
أنظمة messaging الحديثة تستخدم مجموعة مفاتيح وبروتوكولات session establishment وkey rotation.
WhatsApp نشر تفاصيل عن multi-device encryption، ومنها أن لكل جهاز identity key وأن الأجهزة تنشئ pairwise encrypted sessions. citeturn0search0
🛡️ Signal Protocol
WhatsApp يستخدم تقنيات مبنية على Signal Protocol.
لكن Signal Protocol ليس مجرد:
Key Exchange
هو مجموعة بروتوكولات وآليات لبناء جلسات تشفير آمنة وتحديث مفاتيح التشفير.
ومن المفاهيم المهمة:
Identity Keys
Signed Pre Keys
One-Time Pre Keys
Session Establishment
Ratchet
Forward Secrecy
🔄 Forward Secrecy
الفكرة:
لو مفتاح/حالة تشفير معينة تعرضت للخطر في لحظة ما، تصميم البروتوكول يهدف إلى الحد من قدرة المهاجم على استخدام ذلك لكشف كل الرسائل السابقة والمستقبلية.
وده أحد أسباب استخدام key evolution / ratcheting في messaging protocols.
👥 Groups و Sender Keys
في Group فيه:
100
1000
10000
أعضاء.
لو شفرنا الرسالة بشكل مستقل بالطريقة الساذجة لكل عضو في كل مرة، التكلفة قد تصبح كبيرة.
لذلك Signal Protocol لديه:
Sender Keys
Meta توضح أن WhatsApp ما زال يستخدم scalable Sender Key encryption scheme من Signal Protocol للمجموعات في multi-device architecture. citeturn0search0
🟢 Presence
Presence يعني معلومات مثل:
Online
Offline
Last Seen
Typing
لكن مش كل Presence event له نفس أهمية الرسالة.
مثلاً:
Message
يجب أن تكون durable ومضمونة قدر الإمكان.
بينما:
Typing...
event مؤقت.
لو ضاع:
Typing
مش كارثة.
لو ضاعت:
Message
دي مشكلة حقيقية.
💓 Heartbeats
في persistent connection systems غالبًا تحتاج آلية لاكتشاف:
Connection alive?
مثلاً:
Ping
↓
Pong
أو protocol-specific keepalive.
لكن في mobile networking يجب مراعاة:
Battery
NAT
Radio wakeups
OS background restrictions
Network switching
Push notifications
لذلك لا تفترض أن كل هاتف يحتفظ باتصال TCP دائمًا طوال اليوم.
📷 Media
الصورة أو الفيديو ليسا مجرد:
message.body = binary
عادةً يتم التعامل مع media كـ workflow مختلف:
Select media
↓
Compress / Prepare
↓
Encrypt
↓
Upload
↓
Send message metadata/reference
↓
Recipient downloads media
↓
Decrypt
وده أفضل من جعل قناة الرسائل الصغيرة تحمل ملفات ضخمة بالكامل.
☁️ Backup
دي نقطة مهمة جدًا.
لا تخلط بين:
E2EE message transport
و:
Cloud Backup
الـ backup له threat model مختلف.
WhatsApp يوفر:
End-to-End Encrypted Backups
بحيث يستطيع المستخدم تفعيل حماية إضافية للنسخة الاحتياطية باستخدام password/passkey أو مفتاح استرداد، بحسب النظام والخيارات المتاحة حاليًا.
وهذه نقطة مهمة لأن:
Encrypted in transit
لا تعني تلقائيًا:
Encrypted backup
بنفس الطريقة.
🧩 Key Transparency
WhatsApp أضاف أيضًا:
Key Transparency
وهي آلية تساعد على التحقق من أن public identity keys المرتبطة بالحسابات لم يتم تبديلها بشكل خبيث.
Meta توضح أن WhatsApp نشر نظام Key Transparency مبنيًا على Auditable Key Directory. citeturn0search11
🚀 Scaling
لو عندك:
100 users
المشكلة بسيطة.
لكن:
100 Million
1 Billion+
تبدأ الأسئلة الحقيقية:
How many concurrent connections?
How many messages/sec?
How many delivery events?
How many devices/user?
How many group fan-outs?
How much storage?
How many retries?
How much metadata?
How do we route users?
How do we recover from failures?
📨 Queues
لو User Online:
Receive
↓
Deliver
لكن مع scale كبير قد تحتاج:
Ingress
↓
Durable Queue
↓
Delivery Workers
↓
Connection Servers
↓
Recipient
وتستخدم:
Partitioning
Batching
Backpressure
Retry
Dead Letter Handling
حسب الـ workload.
🧱 Backpressure
تخيل أن:
Incoming messages = 1,000,000/sec
لكن consumer يستطيع:
700,000/sec
لو تجاهلت المشكلة:
Queue grows
Memory grows
Latency grows
لذلك تحتاج:
Backpressure
Rate Control
Load Shedding where acceptable
Queue Limits
لكن لا يجوز التعامل مع message delivery بنفس طريقة التعامل مع ephemeral events.
🔁 Retry
لو delivery failed:
Retry
لكن retry بدون limits قد يحول failure إلى:
Retry Storm
لذلك تحتاج:
Backoff
Jitter
Retry limits
Idempotency
Dead-letter / recovery strategy
🧠 أهم مشاكل System Design
لو سألك interviewer:
ماذا لو response ضاع؟
Message ID
+
Idempotency
ماذا لو الرسائل وصلت بترتيب خاطئ؟
Sequence / ordering metadata
+
Sync
ماذا لو المستخدم Offline؟
Durable pending delivery
+
Reconnect
+
Sync
ماذا لو عنده أكثر من جهاز؟
Multi-device identities
+
Encrypted client fan-out
ماذا لو Group فيه آلاف الأشخاص؟
Sender Keys
+
Fan-out
+
Queues
+
Backpressure
ماذا لو Typing event ضاع؟
مش كارثة.
لأنه:
Ephemeral
لكن message:
Durable
🎯 إجابة انترفيو جاهزة
لو interviewer قال:
"WhatsApp شغال إزاي؟"
ممكن تقول:
"هقسم النظام لعدة أجزاء. أولاً عندي real-time communication layer للحفاظ على اتصال مناسب بين client والـ infrastructure، لكن WhatsApp لا يعتمد ببساطة على WebSocket؛ لديه protocol وclient/server architecture خاصة به، تاريخيًا مبنية على XMPP."
ثم:
"عند إرسال message، الـ client ينشئ message ID ويشفّر المحتوى end-to-end. السيرفر لا يحتاج قراءة محتوى الرسالة؛ دوره الأساسي في routing، delivery، synchronization والـ metadata اللازمة للخدمة."
ثم:
"قبل محاولة التسليم، لازم يكون عندي durable state للرسالة أو آلية موثوقة تمنع فقدانها. لو recipient offline، الرسالة تظل pending حتى reconnect ضمن سياسة الاحتفاظ المعتمدة."
ثم:
"لو حصل retry بسبب network failure، message ID يساعدني على idempotency ومنع duplicate delivery. ولو الرسائل وصلت بترتيب مختلف، أحتاج ordering/synchronization mechanism."
ثم:
"في multi-device، كل جهاز له identity مستقلة، وWhatsApp يستخدم client-fanout بحيث يتم تشفير الرسالة لكل device مستهدف. وفي groups يستخدم Sender Keys."
ثم:
"على مستوى scalability أحتاج connection management، queues، partitioning، backpressure، retries، monitoring، وfailure isolation. والـ presence events مثل typing لها durability requirements أقل من actual messages."
⚠️ ملاحظات وتصحيحات مهمة
❌ "كل اتصال Internet يبدأ بـ TCP"
مش دائمًا.
هناك:
TCP
UDP
QUIC
وQUIC يعمل فوق UDP.
❌ "HTTP connection يقفل بعد كل Request"
ليس بالضرورة.
هناك:
Keep-Alive
HTTP/2
HTTP/3
❌ "WhatsApp يستخدم WebSocket"
ده تبسيط زائد.
الأدق:
WhatsApp لديه بروتوكولات وarchitecture خاصة، وقد نشر أنه يستخدم protocol مبنيًا على XMPP في سياقات الاتصال ببنيته. citeturn0search6
❌ "كل هاتف لديه TCP connection مفتوح دائمًا"
على mobile، الـ OS والشبكة والبطارية تجعل هذا غير مضمون.
قد تستخدم:
Persistent connections
Reconnect
Push notifications
Background mechanisms
حسب الحالة.
❌ "FunXMPP هو بالضرورة البروتوكول الحالي بالكامل"
ده historical implementation detail.
الأفضل تقديمه كتاريخ وتقنية من تطور WhatsApp، وليس كـ complete specification للـ WhatsApp الحالي.
❌ "Erlang process = 300 bytes دائمًا"
لا تستخدمها كحقيقة عامة.
Memory usage يعتمد على:
BEAM version
Process state
Heap
Messages
Runtime
Workload
❌ "Server يحتفظ بالرسالة 30 يومًا دائمًا"
الأفضل تقول:
WhatsApp يحتفظ بالرسائل غير المسلّمة مؤقتًا لأغراض التسليم، بينما الرسائل بعد التسليم لا تُحتفظ بها على السيرفر كأرشيف دائم في نموذج WhatsApp multi-device المنشور. citeturn0search0
ولا تجعل رقم 30 يومًا architectural guarantee إلا بمصدر رسمي محدث.
🏆 الخلاصة
WhatsApp ليس:
Frontend
↓
API
↓
Database
فقط.
هو أقرب إلى:
┌──────────────────┐
│ Client Devices │
└────────┬─────────┘
│
Secure Connection
│
▼
┌────────────────────┐
│ Connection Layer │
└─────────┬──────────┘
│
▼
┌────────────────────┐
│ Routing / Delivery│
└─────────┬──────────┘
│
┌──────────┴──────────┐
▼ ▼
Durable State Queues
│ │
└──────────┬──────────┘
▼
Recipient Devices
وفوق كل ده:
End-to-End Encryption
Multi-Device
Key Management
Presence
Ordering
Idempotency
Retry
Backpressure
Observability
فالـ interviewer مش عايزك تقول:
"WhatsApp بيستخدم TCP وErlang."
هو عايز يعرف:
هل أنت قادر تفكر إزاي تبني Messaging System موثوق وآمن ويشتغل على scale ضخم؟
وده هو الفرق بين:
"I know WhatsApp uses X."
و:
"I understand why a system like WhatsApp needs these architectural decisions."
📚 مصادر رسمية
Meta / WhatsApp Engineering
-
How WhatsApp enables multi-device capability
https://engineering.fb.com/2021/07/14/security/whatsapp-multi-device/
المصدر الرسمي الأهم لفهم multi-device، device identity keys، client fan-out، Sender Keys، والـ message storage بعد التسليم. citeturn0search0 -
Deploying key transparency at WhatsApp
https://engineering.fb.com/2023/04/13/security/whatsapp-key-transparency/
عن Key Transparency وAuditable Key Directory. citeturn0search11 -
How Device Verification protects your WhatsApp account
https://engineering.fb.com/2023/04/13/security/whatsapp-device-verification-protects-your-account/
عن authentication keys وآلية device verification. citeturn0search4 -
Messaging interoperability with third parties
https://engineering.fb.com/2024/03/06/security/whatsapp-messenger-messaging-interoperability-eu/
يتضمن وصفًا رسميًا لاتصال third-party clients ببنية WhatsApp باستخدام protocol مبني على XMPP. citeturn0search6
Erlang / Concurrency Background
- Chat Stability and Scalability — Meta Engineering
https://engineering.fb.com/2009/02/17/web/chat-stability-and-scalability/
مثال تاريخي رسمي من Meta عن استخدام Erlang للـ concurrent chat systems. citeturn1search19
<div align="center">
☕ WhatsApp ليس مجرد Chat App
هو Distributed Real-Time System
Networking + Messaging + Encryption + Delivery + Multi-Device + Scalability
</div>منشورات مقترحة
مشاريع ذات صلة
منصة عقارية متكاملة تدعم دورة حياة الإعلانات، وإشعارات الواتساب المباشرة، والبحث الجغرافي بالخريطة في القاهرة والجيزة.