مصطلحات مهمة في عالم الـ System Design 💯 (٨) . . لحد دلوقتي كنا… — DevGuide — TG.ME

مصطلحات مهمة في عالم الـ System Design 💯 (٨)
.
.
لحد دلوقتي كنا بنتكلم عن البيانات العادية.

يعني Users و Products و Orders... وكلها بيانات بتتخزن في قاعدة البيانات بشكل طبيعي.

لكن خليني أسألك سؤال.

لما ترفع صورة على Facebook، أو فيديو على YouTube، أو PDF على Google Drive...

هل الملفات دي بتتخزن داخل الـ Database؟

الإجابة إن قواعد البيانات فعلًا تقدر تخزن ملفات، لكن في الأنظمة الكبيرة غالبًا مش بيكون ده أفضل اختيار.

لأن تخزين الملفات الكبيرة داخل قاعدة البيانات بيكون أقل كفاءة، وأصعب في التوسع، وغالبًا أعلى تكلفة.

علشان كده الأنظمة الكبيرة بتستخدم حل مخصص لتخزين الملفات.

———

📌 Blob Storage

الـ Blob اختصار لـ Binary Large Object.

ببساطة، هو مكان مخصص لتخزين الملفات الكبيرة، زي:

- الصور
- الفيديوهات
- ملفات PDF
- ملفات الصوت
- أي File المستخدم يرفعه

بدل ما نخزن الملف نفسه داخل قاعدة البيانات، بنخزنه في Blob Storage، ونحفظ في الـ Database مجرد رابط الملف أو الـ Metadata الخاصة به.

تخيل إن عندك مكتبة.

الـ Database هي فهرس الكتب.

لكن الكتب نفسها موجودة في المخزن.

لما حد يطلب كتاب، الفهرس يقولك هو موجود فين، وبعدها تروح تجيبه.

وده نفس اللي بيحصل.

علشان كده خدمات زي:

- Amazon S3
- Google Cloud Storage
- Azure Blob Storage

اتعملت مخصوص للغرض ده.

لكن حتى لو الملف متخزن في Blob Storage، لسه فيه مشكلة.

ماذا لو المستخدم موجود في مصر، والملف موجود على سيرفر في أمريكا؟

———

📌 CDN (Content Delivery Network)

تخيل إن عندك شركة لها فرع واحد في القاهرة.

وكل العملاء في إسكندرية وأسوان والمنصورة لازم يروحوا القاهرة كل مرة.

أكيد هيضيعوا وقت كبير.

الحل الطبيعي إنك تفتح فروع في أماكن مختلفة.

وده بالظبط اللي بيعمله الـ CDN.

الـ CDN عبارة عن شبكة من السيرفرات موزعة في دول ومدن مختلفة.

ولما المستخدم يطلب ملف لأول مرة، أو حسب إعدادات الـ CDN، بيتم الاحتفاظ بنسخة منه على سيرفرات قريبة من المستخدمين.

بعد كده، أي مستخدم يطلب نفس الملف غالبًا هيوصله من أقرب سيرفر ليه، بدل ما يروح كل مرة للسيرفر الأصلي.

وده بيقلل الـ Latency بشكل كبير، ويخلي الصور والفيديوهات تفتح أسرع.

علشان كده معظم المواقع الكبيرة بتستخدم CDN، خصوصًا لو عندها مستخدمين من دول مختلفة.

لكن كل اللي اتكلمنا عنه لحد دلوقتي بيعتمد على فكرة واحدة...

الـ Client يطلب، وبعدها السيرفر يرد.

طيب لو السيرفر هو اللي عايز يبعت بيانات من نفسه، من غير ما المستخدم يطلب؟

———

📌 WebSockets

خلينا ناخد مثال.

أنت فاتح تطبيق واتساب.

وصاحبك بعتلك رسالة.

إزاي الرسالة ظهرت عندك فورًا؟

هل التطبيق كل ثانية بيبعت Request للسيرفر يسأله:

"فيه رسالة جديدة؟"

الطريقة دي اسمها Polling، وكانت وما زالت بتستخدم في بعض الحالات، لكنها بتستهلك Requests كتير بدون داعي.

عشان كده في التطبيقات اللي محتاجة تحديثات لحظية، بنستخدم WebSockets.

الـ WebSocket بيعمل اتصال مستمر بين الـ Client والـ Server.

بدل ما كل شوية نفتح Connection جديد، الاتصال يفضل مفتوح.

وبالتالي أول ما يحصل أي تحديث، السيرفر يقدر يبعته مباشرة للـ Client.

وده السبب إننا بنستخدم WebSockets في تطبيقات زي:

- WhatsApp
- Messenger
- Slack
- Discord
- Live Notifications
- Live Dashboards

لأنها محتاجة البيانات توصل في نفس اللحظة تقريبًا.

———

💡 الخلاصة

النهارده عرفنا إزاي الأنظمة الكبيرة بتتعامل مع الملفات، وإزاي بتوصل التحديثات لحظيًا.

• الـ Blob Storage: مكان مخصص لتخزين الملفات الكبيرة بدل قاعدة البيانات، مع الاحتفاظ بالرابط أو الـ Metadata داخل الـ Database.

• الـ CDN: شبكة من السيرفرات بتحتفظ بنسخ من الملفات بالقرب من المستخدمين، علشان تقلل وقت التحميل والـ Latency.

• الـ WebSockets: اتصال مستمر بين الـ Client والـ Server يسمح بإرسال التحديثات لحظيًا، بدل الاعتماد على إرسال Requests متكررة.

———

دلوقتي بقينا نعرف إزاي التطبيقات تخزن الملفات وتبعتها بسرعة للمستخدم.

لكن التطبيقات الكبيرة مش بتكون Service واحدة.

غالبًا بتكون عشرات أو مئات الخدمات، وكل Service محتاجة تتواصل مع التانية.

وده اللي هنتكلم عنه في البوست الجاي، لما نتعرف على Webhooks و Microservices و Message Queues.

———
#system_design
❤5
August 8, 2026 847 11