چند ثانیه سریع‌تر، یک تجربه متفاوت: افزایش سرعت سرویس ثبت آگهی، رضایت کاربران و درآمد!

سال ۱۴۰۱، سرویس ثبت آگهی دیوار، یکی از حیاتی‌ترین بخش‌های پلتفرم، با چالش‌های فزاینده‌ای روبرو بود. با رشد دیوار و افزایش روزانه‌ی تعداد آگهی‌ها، زیرساخت قدیمی که با پایتون نوشته شده بود، دیگر پاسخگوی نیازهای ما نبود. کاربران هنگام ثبت آگهی با کندی و خطا مواجه می‌شدند و این موضوع مستقیماً بر تجربه‌ی آن‌ها و در نتیجه بر موفقیت دیوار تأثیر می‌گذاشت. تیم فنی تصمیم گرفت برای حل ریشه‌ای این مشکلات، سرویس ثبت آگهی را بازنویسی کند. هدف اصلی بهبود پایداری (Reliability) و سرعت سرویس بود، اما نتیجه‌ی کار، یک غافلگیری خوشایند برای همه ما به همراه داشت: بدون اینکه هیچ تغییری در ظاهر یا فرآیند محصولی ثبت آگهی ایجاد کنیم، شاهد بهبود قابل توجه در متریک‌های محصولی و حتی افزایش محسوس درآمد دیوار بودیم!

ماجرا چه بود؟ چالش‌های سرویس قدیمی ثبت آگهی

سرویس قدیمی ثبت آگهی که با زبان پایتون توسعه داده شده بود، در گذر زمان و با افزایش بار ترافیکی، دچار مشکلاتی شده بود که هم کاربران و هم تیم‌های فنی دیوار را آزار می‌داد:

  • کندی و خطاهای مکرر: طراحی قدیمی سرویس دیگر نمی‌توانست حجم بالای درخواست‌ها را به خوبی مدیریت کند. کاربران اغلب با کندی در بارگذاری صفحات فرم ثبت آگهی و حتی خطاهای غیرمنتظره در لحظه‌ی نهایی فشردن دکمه «ثبت آگهی» مواجه می‌شدند. طبق گزارش‌ها، نزدیک به ۱۰ درصد تماس‌های پشتیبانی دیوار ناشی از همین مشکلات در فرآیند ثبت یا ویرایش آگهی بود و حدود ۰.۷۵ درصد درخواست‌های ثبت/ویرایش آگهی با خطای غیرمنتظره مواجه می‌شدند.
  • وابستگی‌های زیاد و شکنندگی: سرویس ثبت آگهی به سرویس‌های داخلی متعددی وابسته بود. بروز مشکل در هر یک از این سرویس‌ها می‌توانست کل فرآیند ثبت آگهی را مختل کند.
  • تجربه‌ی کاربری نامطلوب: کندی و خطاها باعث می‌شد کاربران از ثبت آگهی منصرف شوند یا فرآیند را نیمه‌کاره رها کنند. این تجربه‌ی ناخوشایند، به خصوص برای کاربرانی که برای اولین بار قصد ثبت آگهی داشتند، می‌توانست دلسردکننده باشد.
  • بهره‌وری پایین توسعه‌دهندگان: سرویس قدیمی از کتابخانه‌ای به نام ui schema برای ساخت فرم‌ها استفاده می‌کرد که قدیمی، فاقد type safety و مستندات کافی بود. این موضوع باعث بروز خطاهای زیاد در زمان توسعه، کندی فرآیند توسعه (تا ۲۰٪ کندتر طبق گفته‌ی تیم‌ها) و سختی در افزودن قابلیت‌های جدید می‌شد. مذاکرات مداوم بین تیم‌های بک‌اند و کلاینت برای اطمینان از هماهنگی، زمان زیادی را تلف می‌کرد.

با توجه به این چالش‌ها، در اردیبهشت ۱۴۰۲ تیمی اختصاصی برای بازنویسی کامل سرویس ثبت آگهی تشکیل شد. هدف، ساخت سرویسی به‌روز، پایدار، سریع و توسعه‌پذیر بود.

تغییرات فنی‌ای که دادیم: بازنویسی با نگاهی نو

تیم بازنویسی با هدف رفع مشکلات بنیادی سرویس قدیمی، مجموعه‌ای از تغییرات کلیدی را در معماری و تکنولوژی‌های مورد استفاده اعمال کرد:

  • مهاجرت به Go: زبان Go به دلیل مدیریت بهتر هم‌روندی (Concurrency) و کارایی بالا، به عنوان زبان اصلی سرویس جدید انتخاب شد. این انتخاب به ما کمک کرد تا درخواست‌های همزمان به سرویس‌های وابسته را بهینه‌تر مدیریت کنیم و زمان پاسخ‌دهی کلی را کاهش دهیم.
  • استفاده از Type Safety با Protobuf: برای تعریف ساختار داده‌های آگهی و همچنین کامپوننت‌های فرم، از Protobuf استفاده کردیم. این کار باعث شد کل فرآیند، از بک‌اند تا کلاینت‌ها (اندروید، iOS، وب)، کاملاً Type Safe شود. این یعنی خطاهای ناشی از ناهماهنگی داده‌ها یا اشتباهات تایپی به شدت کاهش یافت و فرآیند توسعه بسیار ساده‌تر و مطمئن‌تر شد. این زیرساخت جدید (که FormPage نام گرفت) جایگزین ui schema قدیمی شد و امکان استفاده از ویجت‌های استاندارد دیوار در فرم‌ها را فراهم کرد.
  • اجرای درخواست‌ها در پس‌زمینه (Online Request): برخی از مراحل ثبت آگهی نیازمند استعلام از سرویس‌های دیگر بودند (مانند استعلام کد ملی از سامانه شاهکار). در سیستم قدیمی، این استعلام‌ها در لحظه‌ی نهایی ثبت انجام می‌شد و کاربر باید منتظر پاسخ می‌ماند. در سرویس جدید، این درخواست‌های زمان‌بر به محض وارد کردن اطلاعات توسط کاربر، در پس‌زمینه ارسال می‌شوند. به این ترتیب، تا کاربر به مراحل پایانی برسد، پاسخ این استعلام‌ها آماده است و کاربر هیچ تأخیری را حس نمی‌کند.
  • مدیریت وابستگی‌های UI در کلاینت (Offline Dependency): در سیستم قبلی، تغییر برخی فیلدها (مثلاً انتخاب نوع کنسول بازی) نیازمند ارسال درخواست به سرور و بارگذاری مجدد بخشی از فرم برای نمایش فیلدهای وابسته (مثلاً مدل کنسول) بود. در سیستم جدید، این وابستگی‌ها به صورت هوشمند در خود کلاینت مدیریت می‌شوند و نیازی به رفت و برگشت اضافه به سرور نیست.
  • کاهش وابستگی‌های خارجی: در طراحی جدید تلاش شد تا حد امکان وابستگی‌های خارجی سرویس ثبت آگهی کاهش یابد تا پایداری کلی سیستم افزایش پیدا کند.

یک اتفاق جالب: وقتی بهبود سرعت و پایداری، محصول را متحول می‌کند!

همانطور که گفتیم، هدف اصلی بازنویسی، بهبود پایداری و سرعت بود. اما پس از انتشار تدریجی سرویس جدید، با نتایج شگفت‌انگیزی در متریک‌های محصولی مواجه شدیم:

  • افزایش محسوس درآمد دیوار: این مهم‌ترین و غیرمنتظره‌ترین نتیجه بود. با اینکه هیچ تغییری در مدل کسب‌وکار یا قیمت‌گذاری‌ها نداده بودیم، صرفاً با بهبود تجربه‌ی فنی ثبت آگهی، درآمد دیوار به طور محسوسی افزایش یافت.
  • افزایش تعداد آگهی‌های موفق: کاربران بیشتری موفق به تکمیل فرآیند ثبت آگهی شدند. نرخ ثبت آگهی موفق نسبت به ورود به فرآیند ثبت، ۴.۱۷٪ افزایش یافت. همچنین نرخ موفقیت کاربرانی که دکمه نهایی «ثبت آگهی» را می‌زدند، ۳۲٪ بهبود پیدا کرد.
  • صرفه‌جویی عظیم در زمان کاربران: به طور میانگین، کاربران ۱۶ ثانیه زودتر فرآیند ثبت آگهی را به پایان می‌رساندند. با توجه به اینکه روزانه حدود یک میلیون آگهی در دیوار ثبت می‌شود، این بهبود به معنای صرفه‌جویی مجموعاً بیش از ۴۴۰۰ ساعت از زمان کاربران دیوار در هر روز است!
  • کاهش چشمگیر تماس‌های پشتیبانی: مشکلات فنی کمتر به معنای نیاز کمتر کاربران به تماس با پشتیبانی بود. سهم مشکلات فنی ثبت آگهی از کل تماس‌های پشتیبانی دیوار از ۰.۲۱٪ به ۰.۰۳٪ کاهش یافت (یعنی تقریباً یک هفتم شد). همچنین درصد تماس‌های مربوط به خطای ثبت آگهی نسبت به کل تماس‌های با موضوع ثبت آگهی، از ۱.۷۱٪ به ۰.۵۴٪ رسید.

این نتایج به وضوح نشان داد که بهبود زیرساخت‌های فنی، حتی اگر برای کاربر نهایی نامرئی باشد، می‌تواند تأثیر مستقیم و قابل توجهی بر رفتار کاربر، موفقیت محصول و در نهایت درآمد شرکت داشته باشد.

این موضوع منحصر به دیوار نیست و پیش‌تر شرکت‌های دیگر نتایج همانندی را گزارش کرده بودند. آمازون به عنوان یک شرکت تجارت الکترونیک، همواره روی سرعت بارگذاری وب‌سایت و سرویس‌های خود حساس بوده است. یک مطالعه‌ی معروف در آمازون نشان داد که حتی تاخیرهای بسیار کوچک نیز مستقیماً بر رضایت و رفتار خرید کاربران اثر می‌گذارد. هر ۱۰۰ میلی‌ثانیه تأخیر اضافی = ۱٪ کاهش فروش!​ در آزمون‌های A/B، حتی اختلاف‌های چند دهم ثانیه‌ای در سرعت صفحه، افت قابل توجهی در درآمد به همراه داشت​.

نتیجه‌ی تغییرات فنی: اعداد سخن می‌گویند

علاوه بر بهبودهای محصولی، سرویس جدید به اهداف فنی اولیه‌ی خود نیز با موفقیت دست یافت:

  • کاهش چشمگیر زمان پاسخ‌دهی (Response Time):
    میانگین زمان پاسخ‌دهی (Upper 50) از ۵۶ میلی‌ثانیه به ۲۵ میلی‌ثانیه کاهش یافت (۵۵٪ بهبود).
    زمان پاسخ‌دهی برای ۹۰٪ درخواست‌ها (Upper 90) از ۳۷۸ میلی‌ثانیه به ۹۷ میلی‌ثانیه کاهش یافت (۷۴٪ بهبود).
    زمان پاسخ‌دهی برای ۹۹٪ درخواست‌ها (Upper 99) از ۱۴۰۱ میلی‌ثانیه به ۲۵۰ میلی‌ثانیه کاهش یافت (۸۲٪ بهبود).
  • افزایش آپتایم (Uptime): آپتایم سرویس از ۹۹.۸۰۰٪ به ۹۹.۹۶۲٪ افزایش یافت.
  • کاهش مصرف منابع: مصرف CPU حدود ۸۹٪ و مصرف RAM حدود ۹۳٪ کاهش یافته است.

بهبود فنی فقط یک کار فنی نیست!

بازنویسی سرویس ثبت آگهی دیوار داستانی از اهمیت سرمایه‌گذاری بر زیرساخت‌های فنی است. پروژه‌ای که با هدف حل مشکلات پایداری و سرعت آغاز شد، نه تنها به اهداف فنی خود رسید، بلکه به طور غیرمنتظره‌ای منجر به بهبود متریک‌های کلیدی محصول و افزایش درآمد شد. این تجربه، در کنار تجربه‌ی مشابه قبلی ما در بهینه‌سازی سرویس تصاویر آگهی‌ها، این باور را در دیوار تقویت کرد که سلامت و کارایی فنی سیستم‌ها، بخشی جدایی‌ناپذیر از موفقیت محصول است. گاهی بهترین راه برای بهبود تجربه‌ی کاربری و رشد محصول، نه افزودن ویژگی‌های جدید، بلکه تقویت پایه‌های فنی سیستم است.

با تشکر از تیم ثبت آگهی - مهدی مصطفوی، مهدی عباسی، مسیح جزایری، همایون علی محمدی، کامیار میرزاوزیری، ایمان نامداری، امین موسوی، محراب صاف دل، متین عبداللهی و دیگر همکاران - که با تلاش و تعهد خود این بازنویسی موفق را به سرانجام رساندند.