كيف نبني منصات تتحمل مليون مستخدم

لحظة الذروة في جولة تبدو هكذا: ستريمر مشهور يبدأ جولة روليت، وخلال ثوانٍ يرسل آلاف المشاهدين أوامرهم في الشات في اللحظة نفسها، وكلهم يتوقعون رؤية النتيجة على البث فوراً. إذا تأخرت المنصة ثانية واحدة، انتهى الحماس. هذه الفقرة تلخص فلسفتنا الهندسية كاملة.

نصمم للنمو قبل أن يحدث

القاعدة الأولى عندنا: لا نبني نموذجاً أولياً ثم «نصلحه لاحقاً». نبدأ من اليوم الأول بقرارات تتحمل النمو:

• خدمات صغيرة مستقلة بدل تطبيق واحد ضخم، بحيث يمكن توسيع الجزء الذي يتعرض للضغط وحده.
• الحالة خارج الخدمة: كل شيء يمكن أن يُفقد عند إعادة تشغيل الخادم يعيش في Redis أو قاعدة البيانات، لا في ذاكرة العملية.
• التخزين المؤقت في طبقات: Cloudflare على الحافة، وRedis في المنتصف، وفهارس مدروسة في قاعدة البيانات.

الوقت الحقيقي بدون مفاجآت

في جولة نعتمد على WebSockets لتوصيل نتائج اللعب لحظياً. الدرس الأهم الذي تعلمناه: الرسائل القليلة المجمّعة أفضل من آلاف الرسائل المنفردة. نجمع أوامر المشاهدين في نوافذ زمنية قصيرة جداً، ونبث تحديثاً واحداً بدلاً من ألف تحديث، فتبقى الشبكة والمتصفح مرتاحين.

نقيس كل شيء

لا يمكن تحسين ما لا تقيسه. لكل خدمة عندنا لوحة مراقبة تعرض زمن الاستجابة عند الشريحة المئوية 99، ومعدل الأخطاء، وطول الطوابير. عندما يرتفع أي رقم نعرف قبل أن يشعر المستخدم، وتصلنا التنبيهات في أي وقت، لأن الدعم عندنا 24/7 ممارسة فعلية لا شعاراً.

نختبر الضغط قبل الجمهور

قبل كل إطلاق كبير نشغّل محاكاة لعشرات الآلاف من المشاهدين المتزامنين. نكسر المنصة في بيئة الاختبار حتى لا تنكسر أمام الجمهور.

الخلاصة

التحمل ليس ميزة تُضاف في النهاية، بل نتيجة لعشرات القرارات الصغيرة الصحيحة من البداية. مليون مستخدم لا يشكّلون تحدياً إذا كنت قد صممت لهم قبل أن يأتوا.