أنظمة الطلبات القائمة على الأحداث: إبقاء الدفع متاحًا تحت الضغط

مشكلة الذروة

يأتي الطلب على توصيل الطعام في ذروات حادة حول أوقات الوجبات. وفي تطبيق واحد، يتنافس البحث في القوائم والتوصيات والتوزيع والدفع على الموارد نفسها من خيوط واتصالات وذاكرة. وقد يستنزف استعلام بطيء في جزء ما الموارد التي يحتاجها الدفع.

احمِ المسار الذي يحصّل المال

كان مبدأ التصميم الأول بسيطًا: يجب أن يستمر الطلب والدفع حتى لو تراجع أداء كل ما عداهما. لذلك فُصلت الطلبات والمدفوعات في خدمات مستقلة بمخازن بيانات خاصة، وجُعل كل تفاعل آخر معها غير متزامن.

أحداث لكل ما يمكنه الانتظار

عند تقديم الطلب يحتاج العميل إلى تأكيد فوري. أما إبلاغ المطعم وتعيين السائق وتحديث التحليلات فيمكن أن تتم بعد لحظة. ويتيح حدث «تم تقديم الطلب» المنشور في Kafka لكل مستهلك أن يعمل بوتيرته، وأن يتعطل دون أن يؤثر على الطلب نفسه.

• خدمة الطلبات: تقبل الطلب وتنشر حدثًا.
• خدمة المطاعم: تستهلك الحدث وتحدّث شاشة المطبخ.
• خدمة التوزيع: تستهلك الحدث وتعيّن سائقًا.
• خدمة الإشعارات: تُبلغ العميل مع وصول أحداث الحالة.

كل خدمة تملك بياناتها

تحتاج الطلبات والمدفوعات إلى معاملات، لذا تُخزن في PostgreSQL. أما قوائم الطعام فمستندات يختلف شكلها من مطعم لآخر، لذا تُخزن في MongoDB. ولا تقرأ أي خدمة جداول خدمة أخرى، بل تُبقي البيانات التي تحتاجها محدّثة عبر الأحداث.

ما التكلفة

الأنظمة القائمة على الأحداث أصعب فهمًا من تطبيق واحد. فالبيانات تتسق مع الوقت، والأعطال قد تحدث بين الخدمات، وتصحيح الأخطاء يعني تتبع الطلب عبر عدة عمليات. والتتبع الموزع، هنا باستخدام Zipkin، والمستهلكون متساوو الأثر (idempotent) هم الحد الأدنى من الاستثمار الذي يجعل هذه البنية قابلة للإدارة.

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