البنية المعمارية خلف تطبيق توصيل عند الطلب

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

يستعرض هذا المقال البنية المعمارية (architecture) خلف تطبيق توصيل عند الطلب: المكوّنات المتحركة، ولماذا توجد، والقرارات المهمة قبل أن تكتب سطرًا واحدًا من الكود أو تعتمد ميزانية.

الأطراف الأربعة ولماذا تشكّل كل شيء

معظم منتجات التوصيل ليست تطبيقًا واحدًا، بل نظامًا يخدم أربعة مستخدمين مختلفين تمامًا، وكلٌّ منهم يجذب البنية في اتجاهه:

• العميل يتصفّح ويطلب ويدفع ويتتبّع. يريد سرعة وخريطة تتحرك فعلًا.
• التاجر (مطعم، صيدلية، بقالة، dark store) يقبل الطلبات أو يرفضها، ويحدّث القائمة والمخزون، ويدير وقت التحضير.
• السائق يستقبل العروض ويقبل المهام ويتنقّل ويبلّغ عن كل خطوة من الاستلام حتى التسليم.
• فريق العمليات يراقب الشبكة بأكملها، ويعيد إسناد الطلبات المتعثّرة، ويعالج المبالغ المستردّة والنزاعات.

نادرًا ما تتشارك هذه الأدوار الشاشات نفسها أو حتى الأجهزة. السائقون والعملاء على الموبايل، وغالبًا ما يُبنى تطبيقهم باستخدام Flutter من قاعدة كود مشتركة. أما التجار فيستخدمون عادةً جهاز POS لوحيًا، ويعمل فريق العمليات على لوحة تحكّم ويب. على البنية أن تغذّي الجميع ببيانات متّسقة من مصدر حقيقة واحد، وهذا تحديدًا ما يجعل تطبيق التوصيل منصة لوجستية (logistics) أكثر منه متجرًا إلكترونيًا بسيطًا.

العمود الفقري: خدمات، لا تطبيق واحد ضخم

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

البنية العملية تقسّم النظام إلى خدمات مركّزة تتحدث عبر واجهات API محدّدة بوضوح:

خدمة الطلب والكتالوج

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

خدمة الإسناد والمطابقة

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

خدمة التتبّع في الوقت الفعلي

تستقبل تدفّقًا من نبضات GPS من السائقين وتدفع المواقع إلى العملاء ولوحة العمليات. هذه الخدمة عالية التردّد وكبيرة الحجم وتتحمّل بيانات قديمة قليلًا، وهي عكس ملف خدمة الطلب تمامًا، ولهذا تُفصل عنها.

خدمة المدفوعات والمحفظة

تلتقط مدفوعات العملاء، وتحسب أرباح السائقين ومستحقات التجار، وتعالج المبالغ المستردّة. يجب أن تكون قابلة للتدقيق وidempotent، بمعنى أن إعادة المحاولة لا يمكن أبدًا أن تخصم من البطاقة مرتين.

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

التتبّع في الوقت الفعلي، الميزة التي يحكم عليك الجميع بها

التتبّع الحي هو أكثر جزء يلاحظه العملاء، وأسرع جزء يكشف ضعف الهندسة. خريطة تتجمّد أو أيقونة سائق "تقفز" فجأة تهدم الثقة في ثوانٍ.

يبدو تدفّق البيانات هكذا:

• يرسل تطبيق السائق إحداثيات GPS كل بضع ثوانٍ عبر اتصال دائم (عادةً WebSockets، وأحيانًا MQTT لكفاءته على شبكات الموبايل الضعيفة).
• تستقبل بوابة الوقت الفعلي هذه النبضات وتتحقّق منها وتمرّرها إلى كل مَن اشترك في ذلك الطلب: العميل ولوحة العمليات.
• تُنعَّم المواقع وغالبًا تُسقَط على الطرق (snap to roads) لتنزلق العلامة بدل أن تقفز، وتُخزَّن المواقع الأخيرة مؤقتًا (cache) ليرى العميل الذي يعيد فتح التطبيق السائقَ فورًا.

تفصيلان هندسيان يصنعان الفارق في الخليج ومصر تحديدًا:

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

هذا برنامج لوجستي متنكّر في هيئة خريطة لطيفة. الخريطة سهلة؛ أما الأنبوب الموثوق الذي يغذّيها فهو العمل الحقيقي.

تماسك النظام تحت الضغط

شبكة التوصيل لها ذُرى حادة ومتوقّعة، الغداء والعشاء وأيام الرواتب وإفطار رمضان، وثمة أنماط تبقيها صامدة خلالها:

• طابور رسائل (مثل Kafka أو RabbitMQ) يقع بين الخدمات ليمتصّ دفعة الطلبات ويعالجها بثبات بدل أن يُسقط محرك الإسناد.
• تدفّق مدفوع بالأحداث يعني أن كل خطوة، "تم الطلب"، "تم إسناد السائق"، "تم الاستلام"، "تم التسليم"، تُطلق حدثًا تتفاعل معه الخدمات الأخرى. هذا يبقي الخدمات مترابطة ترابطًا مرنًا ويجعل الجدول الزمني للطلب سهل إعادة البناء والتدقيق.
• الـ idempotency وإعادة المحاولات تضمن ألّا تنشئ عثرة شبكة طلبًا مكرّرًا أو خصمًا مزدوجًا.
• الفهرسة الجغرافية في قاعدة البيانات (PostGIS أو استراتيجية geohash) تتيح لخدمة الإسناد العثور على السائقين القريبين خلال أجزاء من الثانية بدل مسح كل سائق في المدينة.
• القابلية للمراقبة عبر السجلات المنظّمة والمقاييس والتتبّع، تتيح لفريق العمليات رؤية طلب متعثّر والتدخّل قبل أن يشتكي العميل.

لا شيء من هذا برّاق، لكنه الفارق بين نظام ينجو من نجاحه ونظام ينهار في أفضل لياليه.

أهم النقاط

• تطبيق التوصيل منصة لوجستية تخدم أربعة مستخدمين متمايزين، العميل والتاجر والسائق والعمليات، لا واجهة متجر واحدة.
• تقسيم النظام إلى خدمات مركّزة (طلب، إسناد، تتبّع حي، مدفوعات) يتيح لكلٍّ منها التوسّع باستقلال والفشل بمعزل.
• التتبّع في الوقت الفعلي يُحكَم عليه بقسوة من المستخدمين؛ الاتصالات الموثوقة والتخزين المؤقت دون اتصال وتردّد النبض الذكي أهمّ من الخريطة نفسها.
• الطوابير والتصميم المدفوع بالأحداث وidempotency والفهرسة الجغرافية هي ما يبقي البنية صامدة خلال ذُرى الطلب المتوقّعة.
• ابنِ منذ اليوم الأول لمراعاة شبكات الموبايل غير الموثوقة والذرى الإقليمية الحادة، فإضافتها لاحقًا أكثر كلفة بكثير.

تصميم تطبيق توصيل عند الطلب تحدٍّ لوجستي بقدر ما هو تحدٍّ برمجي، والقرارات المعمارية التي تتّخذها مبكرًا تشكّل تكاليفك وموثوقيتك لسنوات. في SummationWorks نبني أنظمة توصيل وPOS وتتبّع في الوقت الفعلي لعملاء في الخليج ومصر وخارجهما. استكشف خدماتنا لترى منهجنا، وألقِ نظرة على أعمالنا لأمثلة واقعية، أو تواصل معنا لنناقش ما يحتاجه منتجك.