چرا فقط مدت زمان کش را کوتاه نکنیم؟ ⏱️🤔

یک راه‌حل «هکی» و رایج برای حل این مشکل این است که مدت زمان کش L1 (TTL) را خیلی کم کنیم. مثلاً تنظیم کنیم که کش محلی هر ۱۰ ثانیه منقضی شود.

در حالی که این کار بازه‌ی ناسازگاری را کمتر می‌کند، اما واقعاً مشکل را حل نمی‌کند؛ فقط آن را پنهان می‌کند. 🎭

این رویکرد دو مشکل جدید ایجاد می‌کند:

1️⃣ افزایش Latency 🚦: حالا اپلیکیشن شما خیلی بیشتر مجبور است به کش توزیع‌شده L2 (مثل Redis) یا حتی دیتابیس درخواست بزند.

2️⃣ از دست رفتن Efficiency 📉: مزیت اصلی کش L1 این است که کلاً از درخواست شبکه جلوگیری می‌کند. اگر داده‌ها خیلی سریع منقضی شوند، برای بخش عمده‌ای از ترافیک، این مزیت performance را از دست می‌دهید.

برای چیزهایی مثل مجوزهای کاربر (user permissions)، feature flagها یا قیمت‌گذاری، «تقریباً درست» معمولاً کافی نیست. شما به سازگاری فوری (immediate consistency) نیاز دارید. ⚡️

راه‌حل: Redis Pub/Sub به‌عنوان Backplane 📡🧩

برای حل این مشکل، به یک backplane نیاز داریم.Backplane یک کانال ارتباطی است که تمام نودهای اپلیکیشن ما را به هم وصل می‌کند.

وقتی یک cache entry روی یک نود حذف یا به‌روزرسانی می‌شود، یک پیام روی backplane منتشر می‌کنیم. تمام نودهای دیگر مشترک (subscribe) این کانال هستند و به محض دریافت پیام، کلید مربوطه را از کش محلی خودشان حذف می‌کنند. 🗑

ءRedis از قبل انتخاب محبوبی برای کش L2 است، بنابراین کاملاً منطقی است که از قابلیت Pub/Sub آن برای این مکانیزم سیگنال‌دهی استفاده کنیم. 🔔

این فرآیند به این شکل کار می‌کند:

🔸️ءPublisher 🧑‍💻: نودی که داده را تغییر می‌دهد، یک پیام invalidation شامل cache key منتشر می‌کند.

🔹️ءSubscriber 👂: تمام نودها روی این کانال گوش می‌دهند.

🔸️ءAction ⚙️: وقتی پیام می‌رسد، متد HybridCache.RemoveAsync(key) را صدا می‌زنند.