المطلوب
رفع وتنزيل ملفات، مزامنة بين الأجهزة، مشاركة، إشعارات، ونسخ قديمة. أهم متطلب: الداتا متضيعش أبدًا.
المكونات
| المكون | دوره |
|---|---|
| Block Servers | يقسموا الملف blocks (مثلًا ٤MB). كل block ليه hash، يتضغط ويتشفّر ويترفع على cloud storage |
| Metadata DB | بيانات الملفات والنسخ والـ blocks. Relational عشان نحتاج strong consistency (ACID) |
| Notification Service | يبلّغ الأجهزة التانية إن فيه تغيير. Long polling كفاية لأن الإشعارات قليلة ومش محتاجة WebSocket |
| Offline Backup Queue | يحفظ التغييرات لجهاز أوفلاين لحد ما يرجع |
| Cold Storage | للملفات اللي ماحدش بيفتحها — أرخص بكتير |
Delta Sync
عدّلت سطر في ملف كبير؟ بيرتفع الـ block اللي اتغير بس، مش الملف كله. توفير ضخم في الباندويدث.
توفير المساحة والاعتمادية
- De-duplication: blocks بنفس الـ hash تتخزن مرة واحدة. لو اتنين رفعوا نفس الـ PDF، الديسك يشوفه مرة.
- حد أقصى لعدد النسخ القديمة، والأولوية للنسخ الجديدة.
- الـ metadata DB والـ storage فيهم replication في كذا ريجن.
- لو notification server وقع، الـ clients يتوصلوا بسيرفر تاني.
Checklist الملفات
🧠 اختبر نفسك
١) ليه الـ metadata في SQL مش في نفس مخزن الـ blocks؟
لأننا محتاجين strong consistency على أسماء الملفات والنسخ والمشاركة. الـ blocks تخزين كبير ورخيص.
٢) عدّلت ١MB في ملف ٢GB. إيه اللي يترفع؟
الـ block (أو الـ blocks) اللي اتغيرت بس، مش الملف كله.
٣) اتنين عدلوا نفس الملف أوفلاين. مين يكسب؟
اللي وصل السيرفر الأول. التاني يتعمله conflict ويشوف النسختين.
٤) ليه long polling كفاية هنا ومش WebSocket؟
الإشعارات قليلة (ملف اتغير)، مش ستريم رسايل كل ثانية زي الشات.