أمر مهم يجب أخذه بعين الاعتبار هنا هو أن تطبيقات “الدردشة” عادةً ما تنشر المحتوى الفعلي للمشتركين.
في Discourse، لدينا خط أنابيب معقد إلى حد ما يجعل التنفيذ البسيط معقدًا، مما يؤدي إلى كميات كبيرة من حركة المرور.
- ينشر المستخدم ردًا
- يكتشف جميع المستخدمين الذين يطلعون على الموضوع عبر البث أن هناك محتوى جديدًا
- يطلب جميع المستخدمين محتوى المنشور من الخادم (100 مشاهد = 100 طلب)
- نقوم بسحب الصور وتحسينها
- يكتشف جميع المستخدمين الذين يطلعون على الموضوع عبر البث أن هناك محتوى جديدًا
- يطلب جميع المستخدمين محتوى المنشور من الخادم (100 مشاهد = 100 طلب)
(لدينا تحسينات مختلفة، وحدود للسرعة، وإعادة محاولات، وما إلى ذلك، لكن هذه هي الفكرة الأساسية)
يجب أن تعمل جميع هذه الطلبات عبر خط أماننا لضمان أن المستخدم لديه الصلاحية لرؤية المنشور وما إلى ذلك.
إذا كان المحتوى قصيرًا نسبيًا، وتمكنا من إيجاد طريقة لتنفيذ الأمان بطريقة أخف وزنًا لـ “المسار السريع”، فيمكننا حينها توزيع رسائل الدردشة عبر البث. وهذا سيؤدي إلى أداء أفضل بشكل ملحوظ، حيث يمكننا على الأرجح التعامل مع 10000 مستخدم على خادم رقمي صغير بسعة 2 جيجابايت من Digital Ocean بهذا التصميم.
الأمان معقد للغاية. كما أن التخزين المؤقت معقد أيضًا بسبب مشاكل إلغاء التخزين المؤقت.
لذلك، نعم، نحن نفكر بالتأكيد في هذه المشكلة. ولكن كما هو الحال حاليًا…
كثير من المشاهدين المسجلين في موضوع واحد + كثير من المحتوى الجديد في موضوع واحد = فواتير خادم باهظة.