اما داستان اینجا تمام نمی‌شود.
حتی اگر بهترین Caching Pattern را انتخاب کنی، هنوز چند سؤال مهم باقی می‌ماند:
ءCache چه زمانی Expire شود؟
چه زمانی Invalidate شود؟
اگر Redis Down شد چه کنیم؟
اگر یک Key ناگهان میلیون‌ها Request داشت چه؟
اگر TTL تمام شد و هزار Request همزمان Cache Miss شدند چه؟
اینجاست که مفاهیمی مثل:
TTL
Cache Invalidation
Cache Stampede
Cache Penetration
Cache Breakdown
Cache Warming
Distributed Lock
Stale-While-Revalidate
وارد بازی می‌شوند.

پس بالاخره کدام Pattern را انتخاب کنیم؟
جواب حرفه‌ای این نیست که:
«Cache-Aside بهترینه.»
یا:
«Write-Through بهتره.»
جواب این است:
بستگی به Workload و Consistency Requirement دارد.
مثلاً:
ءRead-heavy + تغییرات کم
→ Cache-Aside

ءRead-heavy + نیاز به Cache تازه بعد از Write
→ Cache-Aside + Write-Through

ءRead/Write بسیار سنگین + قابل قبول بودن Async Persistence
→ Write-Behind

ءWrite زیاد + Read کم
→ Write-Around
و در سیستم‌های واقعی حتی ممکن است چند Pattern را همزمان داشته باشی.
در نهایت:
ءCaching یک تکنولوژی نیست.
یک Design Decision است.
و Redis فقط ابزاری است که این تصمیم را پیاده می‌کند.

🔖هشتگ‌ها:
#Redis #Caching #SoftwareEngineering #SystemDesign