مطالعه موردی مهندسی
API اسنپ‌شات محصول Searchwiz
جست‌وجوی محصول کاتالوگ ساعت و جواهر ما را سرچ‌ویز انجام می‌دهد. اول کار، هر درخواست فید مستقیم روی کوئری زنده‌ی ووکامرس اجرا می‌شد. افزونه‌ای نوشتم که همان خواندن‌ها را از یک جدول اسنپ‌شات آماده جواب بدهد.
مسئله تجاری
مصرف‌کننده‌ای که هزاران محصول را می‌خواند، این کار را هر روز و تمام روز تکرار می‌کند. ساختن هر پاسخ از آبجکت زنده‌ی محصول و ویژگی‌ها و تصاویر و موجودی، روی هاست اشتراکی ما کند بود و زمان دیتابیس را از خریدار واقعی می‌گرفت. این یکپارچه‌سازی به داده‌ی قابل‌پیش‌بینی نیاز داشت، بدون اینکه هر لحظه حق اجرای کوئری گران داشته باشد.
آنچه تحویل دادم
- جدول اختصاصی wp_a2_searchwiz_snapshot که برای هر محصول یک سند JSON نرمال‌شده نگه می‌دارد، با زمان‌مهر برای تشخیص تغییر.
- مسیرهای REST زیر searchwiz/v1 به‌علاوه‌ی اندپوینت‌های سازگار با اسنپ‌پی، که همه از همان اسنپ‌شات سرو می‌شوند.
- سازنده‌ی دسته‌ای کرون که هر تیک ۳۰۰ محصول را زیر قفل ۴۵ثانیه‌ای پردازش می‌کند، به‌همراه یک جاب دلتای روزانه که فقط محصولات تغییرکرده را تازه می‌کند.
- کنسول ادمین محافظت‌شده با nonce، با اکشن‌های شروع کامل، شروع دلتا، اجرای یک‌باره، توقف و پاک‌کردن اسنپ‌شات.
- اجازه‌لیست IP با سقف نرخ دقیقه‌ای — ۱۲۰ برای فهرست محصولات و ۳۰۰ برای تک‌محصول — که روی IPهای تأییدشده هم اعمال می‌شود.
رویکرد فنی
- تولید اسنپ‌شات از سرو پاسخ جدا شد، تا بار بازسازی و بار API روی یک درخواست جمع نشوند.
- به‌جای کلید API از اجازه‌لیست IP استفاده کردم، چون مصرف‌کننده آدرس ثابت خزنده‌هایش را منتشر می‌کند؛ یک آپشن هم فهرست داخلی را گسترش می‌دهد.
- هر دسته یک بودجه‌ی زمانی دارد که با فیلتر تنظیم می‌شود، تا بازسازی نه تایم‌اوت شود نه حافظه را بالا ببرد.
- بعد از اولین ساخت کامل، بازآوری دلتا بر اساس زمان‌مهر کار می‌کند؛ پس نگهداری روزانه فقط سراغ چیزی می‌رود که عوض شده.
نتیجه و شواهد
با انتقال خواندن‌ها به اسنپ‌شات، p95 مسیر فهرست محصولات از حدود ۱٫۹ ثانیه به ۰٫۴۲ ثانیه رسید. نسخه‌ی ۱٫۲٫۳ همین حالا در پروداکشن است و هم سرچ‌ویز و هم فید محصول اسنپ‌پی را تغذیه می‌کند.
اهمیت برای کارفرما
فروشگاه حالا می‌تواند کاتالوگش را با هزینه‌ی ثابت و پایین در هر درخواست به مصرف‌کننده‌های بیرونی بدهد. این یکپارچه‌سازی را از ریسک هاستینگ به کانال فروش تبدیل می‌کند.
عمق اجرای پروژه
این یکپارچه‌سازی را از سر تا ته خودم بردم: خط داده، سیاست دسترسی، و ابزاری که تیم با آن راهبری‌اش می‌کند.
- اسکیمای اسنپ‌شات و ماشین‌حالت پردازش دسته‌ای را خودم طراحی کردم.
- مسیر اندپوینت‌ها را با مستندات منتشرشده‌ی مصرف‌کننده‌ها هم‌شکل کردم، از جمله مسیر فید اسنپ‌پی.
- کنترل بازسازی را داخل wp-admin گذاشتم، تا نگهداری به SSH نیاز نداشته باشد.
خلاصه اجرایی خوانا
خلاصه_اجرایی {
پروژه: "A2 Searchwiz Product API"
پشته: "افزونه‌ی وردپرس، PHP، ووکامرس، WP REST API"
نسخه: "1.2.3"
مسیرها: "searchwiz/v1/products و /product، فید سازگار اسنپ‌پی"
جدول: "wp_a2_searchwiz_snapshot، یک سند JSON در هر محصول"
جاب‌ها: "تیک اسنپ‌شات (۳۰۰ در هر دسته، قفل ۴۵ثانیه)،
کرون دلتای روزانه"
دسترسی: "اجازه‌لیست IP؛ نرخ ۱۲۰/دقیقه فهرست، ۳۰۰/دقیقه تکی"
نتیجه: "p95 فهرست محصولات ۱٫۹ ثانیه ← ۰٫۴۲ ثانیه در پروداکشن"
}ارزش حرفه‌ای این پروژه
جداکردن تولید اسنپ‌شات از سرو پاسخ، تصمیمی است که بقیه‌ی معماری از آن بیرون آمده. یکپارچه‌سازی‌ای که مستقیم روی داده‌ی زنده سوار شود، بالاخره یک روز شلوغ فروشگاه را زمین می‌زند.
سقف نرخ حتی برای IPهای تأییدشده عمدی است. اعتماد دلیل نمی‌شود سقف را برداریم؛ یک باگ ساده در سمت شریک هم می‌تواند همان بلای حمله را سر ما بیاورد.