tgoop.com/bigdata_ir/350
Last Update:
چند ثانیه سریع‌تر، یک تجربه متفاوت: افزایش سرعت سرویس ثبت آگهی، رضایت کاربران و درآمد!
این مطلب از وبلاگ مهندسی دیوار در وب سایت ویرگول برداشته شده است . آدرس اصلی مقاله : yun.ir/divar01
سال ۱۴۰۱، سرویس ثبت آگهی دیوار، یکی از حیاتی‌ترین بخش‌های پلتفرم، با چالش‌های فزاینده‌ای روبرو بود. با رشد دیوار و افزایش روزانه‌ی تعداد آگهی‌ها، زیرساخت قدیمی که با پایتون نوشته شده بود، دیگر پاسخگوی نیازهای ما نبود. کاربران هنگام ثبت آگهی با کندی و خطا مواجه می‌شدند و این موضوع مستقیماً بر تجربه‌ی آن‌ها و در نتیجه بر موفقیت دیوار تأثیر می‌گذاشت.
تیم فنی تصمیم گرفت برای حل ریشه‌ای این مشکلات، سرویس ثبت آگهی را بازنویسی کند. هدف اصلی بهبود پایداری (Reliability) و سرعت سرویس بود، اما نتیجه‌ی کار، یک غافلگیری خوشایند برای همه ما به همراه داشت: بدون اینکه هیچ تغییری در ظاهر یا فرآیند محصولی ثبت آگهی ایجاد کنیم، شاهد بهبود قابل توجه در متریک‌های محصولی و حتی افزایش محسوس درآمد دیوار بودیم!
ماجرا چه بود؟ چالش‌های سرویس قدیمی ثبت آگهی
سرویس قدیمی ثبت آگهی که با زبان پایتون توسعه داده شده بود، در گذر زمان و با افزایش بار ترافیکی، دچار مشکلاتی شده بود که هم کاربران و هم تیم‌های فنی دیوار را آزار می‌داد:
🦀 کندی و خطاهای مکرر: طراحی قدیمی سرویس دیگر نمی‌توانست حجم بالای درخواست‌ها را به خوبی مدیریت کند. کاربران اغلب با کندی در بارگذاری صفحات فرم ثبت آگهی و حتی خطاهای غیرمنتظره در لحظه‌ی نهایی فشردن دکمه «ثبت آگهی» مواجه می‌شدند. طبق گزارش‌ها، نزدیک به ۱۰ درصد تماس‌های پشتیبانی دیوار ناشی از همین مشکلات در فرآیند ثبت یا ویرایش آگهی بود و حدود ۰.۷۵ درصد درخواست‌های ثبت/ویرایش آگهی با خطای غیرمنتظره مواجه می‌شدند.
🦀 وابستگی‌های زیاد و شکنندگی: سرویس ثبت آگهی به سرویس‌های داخلی متعددی وابسته بود. بروز مشکل در هر یک از این سرویس‌ها می‌توانست کل فرآیند ثبت آگهی را مختل کند.
🦀 تجربه‌ی کاربری نامطلوب: کندی و خطاها باعث می‌شد کاربران از ثبت آگهی منصرف شوند یا فرآیند را نیمه‌کاره رها کنند. این تجربه‌ی ناخوشایند، به خصوص برای کاربرانی که برای اولین بار قصد ثبت آگهی داشتند، می‌توانست دلسردکننده باشد.
🦀 بهره‌وری پایین توسعه‌دهندگان: سرویس قدیمی از کتابخانه‌ای به نام ui schema برای ساخت فرم‌ها استفاده می‌کرد که قدیمی، فاقد type safety و مستندات کافی بود. این موضوع باعث بروز خطاهای زیاد در زمان توسعه، کندی فرآیند توسعه (تا ۲۰٪ کندتر طبق گفته‌ی تیم‌ها) و سختی در افزودن قابلیت‌های جدید می‌شد. مذاکرات مداوم بین تیم‌های بک‌اند و کلاینت برای اطمینان از هماهنگی، زمان زیادی را تلف می‌کرد.
با توجه به این چالش‌ها، در اردیبهشت ۱۴۰۲ تیمی اختصاصی برای بازنویسی کامل سرویس ثبت آگهی تشکیل شد. هدف، ساخت سرویسی به‌روز، پایدار، سریع و توسعه‌پذیر بود.
🧠 تغییرات فنی‌ای که دادیم: بازنویسی با نگاهی نو
برای مشاهده ادامه مطلب به سایت ویرگول و وبلاگ فنی دیوار مراجعه کنید.
BY مهندسی داده
Share with your friend now:
tgoop.com/bigdata_ir/350