دراپ یک پلتفرم TravelTech را برای بازار اروپا از صفر تا Production توسعه داد؛ از رزرو هتل و پرواز و پرداخت بینالمللی تا ساخت برنامه سفر با هوش مصنوعی در کمتر از ۳۰ ثانیه.
گفتوگو درباره سیستم شمایک شرکت فعال در بازار سفر اروپا میخواست محصولی بسازد که فراتر از یک سامانه رزرو معمولی باشد: پلتفرمی یکپارچه برای جستوجو و رزرو هتل، خرید بلیت پرواز، تهیه پکیج ترکیبی پرواز و هتل و برنامهریزی کامل سفر با کمک هوش مصنوعی.
دراپ از سال ۲۰۲۳ معماری فنی و توسعه محصول را از صفر آغاز کرد. بهجز طراحی UI/UX و مدیریت محصول که در سمت مشتری انجام میشد، مسئولیت Backend، Frontend، اپلیکیشن موبایل، قابلیتهای هوش مصنوعی، QA، زیرساخت و DevOps با دراپ بود.
محصول در سال ۲۰۲۴ وارد Production شد و رزروهای واقعی را پردازش کرد. توسعه و پشتیبانی فنی نیز تا زمان انتقال کامل محصول به تیم مشتری در کشور مقصد در سال ۲۰۲۵ ادامه پیدا کرد.
• ساخت برنامه سفر شخصیسازیشده با هوش مصنوعی در کمتر از ۳۰ ثانیه • دستیابی به آپتایم بالاتر از ۹۹.۹۵٪ در Production • Test Coverage بالاتر از ۸۰٪ • ورود محصول به بازار اروپا و پردازش رزروهای واقعی • اتصال به Hotelbeds، GIATA و چندین تأمینکننده بینالمللی دیگر • دسترسی به موجودی جهانی شامل صدها هزار گزینه اقامتی • استقرار خودکار در محیطهای مستقل Development، Staging و Production
در یک پلتفرم سفر، چیزی که کاربر به شکل یک جستوجو یا رزرو ساده میبیند، در پشت صحنه به چندین سیستم مستقل وابسته است. قیمت و ظرفیت هتل و پرواز پیوسته تغییر میکند، هر Provider قرارداد داده و رفتار متفاوتی دارد و نتیجهای که چند لحظه قبل معتبر بوده ممکن است هنگام پرداخت دیگر در دسترس نباشد.
محصول باید کل چرخه رزرو را مدیریت میکرد: دریافت و یکسانسازی اطلاعات از چند Provider، کنترل قیمت و موجودی لحظهای، جلوگیری از رزرو تکراری، هماهنگی وضعیت پرداخت و رزرو، مدیریت خطا و Timeout، رعایت Rate Limitها و رسیدگی به کنسلی و Refund.
در کنار این جریان تراکنشی، هوش مصنوعی باید اطلاعاتی مانند بودجه، مقصد، مدت سفر، موقعیت هتل، علایق مسافر، فاصله مکانها و ساعات فعالیت آنها را به یک برنامه سفر روزبهروز و قابل استفاده تبدیل میکرد.
Backend محصول با Node.js و NestJS توسعه داده شد. برای معماری، بهجای حرکت زودهنگام به سمت Microservices، یک Modular Monolith انتخاب کردیم؛ تصمیمی آگاهانه برای حفظ مرزهای روشن میان دامنههای محصول، بدون تحمیل هزینه عملیاتی و پیچیدگی توزیعشدگی در مرحلهای که محصول هنوز در حال شکلگیری بود.
این ساختار اجازه میداد بخشهای مختلف محصول مستقل و قابل نگهداری توسعه پیدا کنند، در حالی که انتشار، تست و عیبیابی سیستم همچنان ساده و کنترلپذیر باقی میماند.
MongoDB پایگاه داده اصلی محصول بود، Redis برای Caching استفاده شد و RabbitMQ از جریانهای پردازشی غیرهمزمان پشتیبانی میکرد. Frontend وب با Next.js و اپلیکیشن موبایل با React Native توسعه یافت تا محصول در وب، iOS و Android تجربهای منسجم داشته باشد.
پلتفرم با Hotelbeds، GIATA و چندین Provider بینالمللی دیگر یکپارچه شد و به موجودی جهانی شامل صدها هزار گزینه اقامتی دسترسی پیدا کرد. ارزش فنی پروژه، با این حال، صرفن در اتصال چند API نبود.
ساختار داده، قواعد قیمتگذاری، وضعیت موجودی، سیاست کنسلی و مدل خطای هر Provider با دیگری تفاوت داشت. لایه Integration باید این تفاوتها را به یک مدل قابل اتکا برای محصول تبدیل میکرد و در برابر Timeout، پاسخ ناقص، تغییر قیمت، Rate Limit و Webhookهای تکراری رفتار کنترلشدهای داشت.
کنترل Idempotency و جلوگیری از ثبت عملیات تکراری در مسیر رزرو اهمیت ویژهای داشت. وضعیت پرداخت در Stripe نیز باید با نتیجه نهایی رزرو هماهنگ میشد تا خطای یکی از سرویسهای بیرونی به رزرو تکراری، پرداخت بلاتکلیف یا تجربه نامشخص برای کاربر منجر نشود.
بخش AI محصول برای تولید یک پیشنهاد عمومی یا متن تزئینی ساخته نشده بود. هدف این بود که محدودیتها و ترجیحات واقعی مسافر را به یک برنامه عملی تبدیل کند.
کاربر اطلاعاتی مانند مقصد، تاریخ، تعداد روزهای سفر، بودجه، محل اقامت و علایق خود را وارد میکرد. سیستم با در نظر گرفتن فاصله مکانها، موقعیت هتل، ساعات فعالیت جاذبهها و زمان قابل استفاده در هر روز، یک Itinerary روزبهروز پیشنهاد میداد.
برنامه تولیدشده قابل ویرایش و بازتولید بود و فرایند ساخت آن در کمتر از ۳۰ ثانیه انجام میشد؛ سرعتی که استفاده از AI را در جریان واقعی برنامهریزی سفر ممکن میکرد، نه صرفن در قالب یک Demo. نام مدل و جزئیات داخلی Pipeline هوش مصنوعی برای حفظ محرمانگی منتشر نمیشود.
محصول فقط محل خرید هتل و پرواز نبود. در پنل کاربر ابزارهایی مانند Notes، Checklist، Friends و Budgeting برای ثبت اطلاعات، مدیریت کارها، هماهنگی با همراهان و کنترل هزینههای سفر در نظر گرفته شده بود.
کاربر همچنین میتوانست رزروها، پرداختها، کنسلیها و Refundهای خود را مشاهده و مدیریت کند. پنل مدیریت نیز امکان کنترل کاربران، رزروها، پرداختها و فرایندهای عملیاتی محصول را در اختیار تیم کسبوکار قرار میداد.
قابلیت Group Trip برای توسعه در نقشه راه محصول در نظر گرفته شده بود، اما در محدوده قابلیتهای منتشرشده این کیس استادی قرار ندارد.
پرداخت آنلاین از طریق Stripe پیادهسازی شد و جریانهای پرداخت، رزرو، کنسلی و Refund به شکلی هماهنگ طراحی شدند.
برای ارتباطات تراکنشی، محصول با Twilio و SendGrid یکپارچه شد. کدهای OTP، رسید خرید، Invoice، یادآوری سفر و سایر پیامهای ضروری از طریق این زیرساخت برای کاربران ارسال میشدند.
زیرساخت و DevOps محصول توسط دراپ طراحی و اجرا شد. سرویسها Containerized بودند و با توجه به نیازها و شرایط فنی پروژه در آن مقطع، Docker Swarm بهعنوان Orchestrator انتخاب شد.
Pipelineهای CI/CD فرایندهای Build، Test و Deployment را خودکار میکردند و محیطهای Development، Staging و Production از یکدیگر جدا بودند. تغییرات پیش از رسیدن به کاربران واقعی در چند مرحله بررسی میشدند و انتشار نسخهها به یک فرایند تکرارپذیر و کنترلشده تبدیل شده بود.
Monitoring، Sentry و ELK امکان ردیابی خطاهای اپلیکیشن، وضعیت سرویسها و لاگهای عملیاتی را فراهم میکردند. محصول در دوره بهرهبرداری به آپتایم بالاتر از ۹۹.۹۵٪ رسید.
وجود چندین Provider خارجی، پرداخت آنلاین و جریانهای پیچیده رزرو باعث میشد تست فقط به بررسی رابط کاربری محدود نباشد. سناریوهای جستوجو، رزرو، پرداخت، خطا، کنسلی و Refund باید در وضعیتهای مختلف بررسی میشدند.
تیم QA در کنار تیمهای Backend، Frontend، Mobile و DevOps در چرخه توسعه حضور داشت و Test Coverage پروژه به بیش از ۸۰٪ رسید. این پوشش، بهویژه هنگام تغییر Integrationها یا توسعه قابلیتهای جدید، ریسک ایجاد Regression در جریانهای اصلی محصول را کاهش میداد.
این پروژه بدون Codebase یا زیرساخت قبلی آغاز شد و به یک محصول عملیاتی در بازار اروپا رسید؛ محصولی که جستوجو و رزرو سفر، پرداخت بینالمللی، مدیریت سفر و برنامهریزی مبتنی بر هوش مصنوعی را در یک تجربه واحد کنار هم قرار میداد.
پلتفرم در سال ۲۰۲۴ وارد Production شد و رزروهای واقعی را پردازش کرد. دراپ پس از راهاندازی نیز توسعه و پشتیبانی فنی آن را ادامه داد و در سال ۲۰۲۵ محصول به تیم مشتری در کشور مقصد منتقل شد.
این پروژه نمونهای از رویکرد دراپ به Product Engineering است: تصمیم معماری متناسب با مرحله محصول، یکپارچهسازی مسئولانه با سرویسهای حساس بیرونی، استفاده کاربردی از هوش مصنوعی و مالکیت فنی مسیر از اولین خط کد تا Production.
اگر در حال ساخت محصولی هستید که نرمافزار پیچیده، AI، یکپارچهسازیهای متعدد و زیرساخت قابل اتکا را کنار هم میخواهد، دراپ میتواند مسئولیت یکپارچه مسیر مهندسی تا Production را بر عهده بگیرد. همکاری را با یک جلسه بررسی محصول و معماری آغاز کنید.