برای یک سرویس کوتاه‌کننده لینک مدرن، کسری از ثانیه می‌تواند تفاوت میان یک کمپین موفق یا از دست رفتن بودجه تبلیغاتی باشد. در این مقاله به تشریح فنی نحوه پیاده‌سازی معماری لایه‌ای کش در URLT 2.0 می‌پردازیم که چگونه زمان پاسخگویی هدایت لینک‌ها را به زیر ۳ میلی‌ثانیه رسانده است.
۱. مشکل مراجعه مستقیم به پایگاه داده در ترافیک بالا
در روش‌های سنتی، به ازای هر بار کلیک کاربر، یک کوئری SELECT روی جدول لینک‌ها اجرا می‌شود. در لحظاتی که یک کمپین ایمیلی یا تبلیغ تلویزیونی فعال می‌شود، هجوم هزاران درخواست همزمان می‌تواند صف اتصالات پایگاه داده (Connection Pool) را پر کرده و منجر به خطای 504 Gateway Timeout شود.
۲. پیاده‌سازی کش کلید-مقدار در حافظه موقت (RAM)
در URLT، به محض ساخت لینک، تمامی فراداده‌های لازم برای هدایت (مقصد، وضعیت، پسورد و انقضا) در سرور حافظه مقیم Redis با الگوی کلید زیر ذخیره می‌شوند:
// کلید کش در ردیس
link:default:{slug} -> {
"destinationUrl": "https://example.com/target",
"status": "ACTIVE",
"hasPassword": false,
"expiresAt": null
}۳. چالش Invalidation آنی کش در ویرایش لینک
بزرگ‌ترین معضل کش‌های با TTL بالا، عدم انعکاس تغییرات هنگام ویرایش لینک توسط کاربر است. ما الگوریتم Cache Eviction رویدادمحور را پیاده کرده‌ایم: به محض دریافت درخواست ویرایش در کنترلر Links، رکورد دیتابیس بروزرسانی شده و بلافاصله فرمان DEL روی کلید Redis صادر می‌شود.
به محض ذخیره مقصد جدید در پنل کاربری، کلیک بعدی در سراسر جهان بلافاصله به مقصد تازه فرستاده می‌شود.
نتیجه‌گیری و جمع‌بندی
تلفیق پایگاه داده رابطه‌ای PostgreSQL برای ذخیره امن ساختارها، همراه با حافظه پرسرعت Redis برای ریدایرکت آنی، URLT را به یکی از پایدارترین و سریع‌ترین بسترهای مدیریت پیوند در وب فارسی تبدیل کرده است.