طورت Dropp منصة TravelTech أوروبية من الصفر، من حجز الفنادق والرحلات والمدفوعات الدولية إلى إنشاء برامج سفر بالذكاء الاصطناعي خلال أقل من 30 ثانية.
ناقش نظامك معناأرادت شركة تعمل في سوق السفر الأوروبية بناء منتج يتجاوز محرك الحجز التقليدي: منصة موحّدة لحجز الفنادق، وشراء تذاكر الطيران، وتجميع باقات الطيران والفندق، وتخطيط الرحلات بمساعدة الذكاء الاصطناعي.
بدأت Dropp في عام 2023 تصميم المعمارية التقنية وتطوير المنتج من الصفر. تولّى العميل إدارة المنتج وتصميم UI/UX، بينما تحملت Dropp مسؤولية تطوير Backend وFrontend وتطبيق الهاتف وقدرات الذكاء الاصطناعي وضمان الجودة والبنية التحتية وDevOps.
دخلت المنصة بيئة Production في عام 2024 وعالجت حجوزات فعلية. واستمرت Dropp في تطوير المنتج ودعمه حتى تسليمه بالكامل إلى فريق العميل في بلد التشغيل عام 2025.
• إنشاء برنامج سفر شخصي بالذكاء الاصطناعي خلال أقل من 30 ثانية • جاهزية تشغيلية تجاوزت 99.95٪ في Production • تغطية اختبارات آلية تجاوزت 80٪ • إطلاق فعلي في السوق الأوروبية ومعالجة حجوزات حقيقية • تكامل مع Hotelbeds وGIATA وعدة مزودين دوليين آخرين • الوصول إلى مخزون عالمي يضم مئات الآلاف من خيارات الإقامة • نشر آلي عبر بيئات Development وStaging وProduction منفصلة
ما يراه المسافر عملية بحث أو حجز بسيطة يعتمد في الخلفية على عدة أنظمة مستقلة. تتغير أسعار الفنادق والرحلات وتوافرها باستمرار، وقد تتبدل النتيجة بين البحث والدفع، كما يستخدم كل مزود بنية بيانات وسلوكًا تشغيليًا مختلفًا.
كان على المنصة إدارة دورة الحجز كاملة: جمع بيانات المزودين وتوحيدها، والتحقق من السعر والتوافر لحظيًا، ومنع الحجوزات المكررة، ومزامنة حالة الدفع والحجز، والتعامل مع Timeout والأخطاء الجزئية، واحترام Rate Limits، ودعم الإلغاء واسترداد الأموال.
وبالتوازي مع هذه التدفقات، كان على طبقة الذكاء الاصطناعي تحويل الميزانية والوجهة ومدة الرحلة وموقع الفندق واهتمامات المسافر والمسافات وساعات العمل إلى برنامج يومي عملي.
طُوّر Backend باستخدام Node.js وNestJS. وبدل الانتقال المبكر إلى Microservices، اختارت Dropp معمارية Modular Monolith؛ قرارًا مقصودًا يحافظ على حدود واضحة بين مجالات المنتج من دون فرض الكلفة التشغيلية وتعقيد الأنظمة الموزعة قبل الحاجة إليهما.
أتاح هذا النهج تطوير أجزاء المنتج كوحدات قابلة للصيانة مع إبقاء النشر والاختبار واستكشاف الأخطاء تحت السيطرة، كما أبقى الباب مفتوحًا لفصل الأجزاء التي تحتاج إلى ذلك مستقبلًا من دون إعادة كتابة النواة.
استُخدمت MongoDB قاعدة بيانات رئيسية، وRedis للتخزين المؤقت، وRabbitMQ لمعالجة التدفقات غير المتزامنة. بُني تطبيق الويب باستخدام Next.js، بينما وفّر React Native أساسًا موحّدًا لتطبيقي iOS وAndroid.
تكاملت المنصة مع Hotelbeds وGIATA وعدة مزودين دوليين آخرين، ما أتاح الوصول إلى مخزون عالمي يضم مئات الآلاف من خيارات الإقامة. لكن القيمة الهندسية للمشروع لم تكن مجرد ربط مجموعة من APIs.
اختلف كل مزود في بنية البيانات وقواعد التسعير وسلوك التوافر وسياسات الإلغاء ونماذج الأخطاء. وكان على طبقة التكامل تحويل هذه الاختلافات إلى نموذج موثوق للمنتج، مع التعامل المنضبط مع Timeout والاستجابات الناقصة وتغير الأسعار وRate Limits وتكرار Webhooks.
كانت Idempotency ومنع الحجز المكرر من العناصر الحساسة في التدفق. كما كان يجب مزامنة حالة الدفع عبر Stripe مع النتيجة النهائية للحجز حتى لا يؤدي فشل خدمة خارجية إلى حجز مكرر أو دفعة معلقة أو نتيجة غامضة للمستخدم.
لم تُضف ميزة الذكاء الاصطناعي لإنتاج نصوص سفر عامة، بل لتحويل تفضيلات المسافر وقيوده الفعلية إلى خطة قابلة للتنفيذ.
كان المستخدم يحدد الوجهة والتواريخ ومدة الرحلة والميزانية وموقع الفندق واهتماماته. ويأخذ النظام في الحسبان المسافات وموقع الإقامة وساعات عمل المعالم والوقت المتاح في كل يوم لبناء برنامج منظم يومًا بيوم.
كان بالإمكان تعديل الخطة أو إعادة إنشائها، وكانت عملية بناء البرنامج تستغرق أقل من 30 ثانية؛ سرعة تجعل الذكاء الاصطناعي جزءًا عمليًا من تجربة التخطيط، لا مجرد عرض تجريبي. ويظل اسم النموذج وتفاصيل AI Pipeline الداخلية سرية.
لم يكن المنتج مجرد مكان لشراء الرحلات والفنادق. فقد ضمت لوحة المستخدم أدوات Notes وChecklists وFriends وBudgeting لتنظيم المعلومات والاستعداد للسفر والتنسيق مع المرافقين وإدارة النفقات.
كما أمكن للمستخدم مشاهدة الحجوزات والمدفوعات وطلبات الإلغاء واسترداد الأموال وإدارتها. ومنحت لوحة الإدارة فريق الأعمال تحكمًا تشغيليًا في المستخدمين والحجوزات والمدفوعات والتدفقات المرتبطة بها.
كانت ميزة Group Trip ضمن خريطة التطوير المستقبلية، ولا تُعرض في دراسة الحالة هذه باعتبارها جزءًا من نطاق Production الذي تم تسليمه.
نُفذت المدفوعات الإلكترونية عبر Stripe، وصُممت حالات الدفع والحجز والإلغاء واسترداد الأموال كتدفقات مترابطة.
استُخدم Twilio وSendGrid لإرسال رموز OTP وإيصالات الشراء والفواتير وتذكيرات السفر وغيرها من الإشعارات الأساسية للمستخدمين.
صممت Dropp البنية التحتية وأساس DevOps للمنصة ونفذتهما. كانت الخدمات Containerized، واختير Docker Swarm بوصفه Orchestrator مناسبًا للاحتياجات التقنية والتشغيلية للمنتج في تلك المرحلة.
أتمتت CI/CD Pipelines عمليات Build وTest وDeployment عبر بيئات Development وStaging وProduction منفصلة. وكانت التغييرات تمر بمراحل تحقق متعددة قبل وصولها إلى المستخدمين، ما جعل الإصدارات قابلة للتكرار والتحكم.
وفّرت أدوات Monitoring وSentry وELK رؤية واضحة لأخطاء التطبيق وحالة الخدمات والسجلات التشغيلية. وخلال التشغيل الفعلي حافظت المنصة على جاهزية تجاوزت 99.95٪.
مع تعدد المزودين الخارجيين والمدفوعات الإلكترونية وتعقيد تدفقات الحجز، لم يكن من الممكن حصر الجودة في اختبار الواجهات. كان يجب التحقق من سيناريوهات البحث والحجز والدفع والفشل والإلغاء واسترداد الأموال عبر حالات متعددة للنظام.
عمل فريق QA إلى جانب فرق Backend وFrontend وMobile وDevOps طوال دورة التطوير. وتجاوزت تغطية الاختبارات الآلية 80٪، ما خفّض مخاطر Regression عند تغير Integrations أو إضافة قدرات جديدة.
بدأ المشروع من دون Codebase أو بنية تحتية سابقة، وانتهى بمنتج عامل في السوق الأوروبية يجمع البحث والحجز والمدفوعات الدولية وإدارة الرحلة والتخطيط بالذكاء الاصطناعي ضمن تجربة واحدة.
أُطلقت المنصة في عام 2024 وبدأت معالجة حجوزات فعلية. واصلت Dropp التطوير والدعم التشغيلي بعد الإطلاق، ثم سُلّم المنتج إلى فريق العميل في بلد التشغيل عام 2025.
يعكس هذا المشروع منهج Dropp في هندسة المنتجات: معمارية مناسبة لمرحلة المنتج، وتكامل مسؤول مع خدمات خارجية حساسة للمعاملات، واستخدام عملي للذكاء الاصطناعي، وملكية تقنية تمتد من أول سطر برمجي حتى Production.
إذا كنتم تبنون منتجًا يجمع البرمجيات المعقدة والذكاء الاصطناعي وتكاملات متعددة وبنية تحتية موثوقة، يمكن لـDropp تولي المسؤولية المتكاملة عن المسار الهندسي حتى Production. ابدأوا بمراجعة للمنتج والمعمارية.