اما تصور کنید:

Account Balance
Payment Status
Inventory
Available Seats

اینجا نمی‌توانیم به کاربر بگوییم:

«نگران نباش، چند ثانیه دیگه درست میشه!» 😐

در این سناریوها Consistency بخشی از Business Requirement است.
🎯 پس قبل از طراحی Cache این سؤال‌ها را بپرسید:
❓ء Source of Truth کجاست؟
❓ چه مدت Stale Data قابل قبول است؟
❓ آیا Strong Consistency لازم داریم یا Eventual Consistency کافی است؟
❓ چه چیزی Cache را Invalidate می‌کند؟
❓ اگر دو Request همزمان Update کنند چه اتفاقی می‌افتد؟
❓ اگر Redis Down شود چه می‌شود؟
❓ اگر Cache قبل از Database Update شود چه؟
❓ اگر Database Update شود اما Invalidation شکست بخورد چه؟
❓ اگر چند Instance همزمان Cache را Populate کنند چه؟
این‌ها همان سؤال‌هایی هستند که تفاوت بین:
«ما Redis داریم»
و
«ما یک Cache درست طراحی کرده‌ایم»
را مشخص می‌کنند. 🚀
💡 نکته نهایی
ءCache کردن Data ساده است.

GET
 ↓
Redis
 ↓
MISS
 ↓
Database
 ↓
SET

اما Cache Design ساده نیست.
به محض اضافه شدن Cache، شما یک State دوم وارد سیستم کرده‌اید.
از این لحظه باید علاوه بر Performance به این موارد هم فکر کنید:
Consistency
Invalidation
Concurrency
TTL
Failure
Race Condition
Source of Truth
Scalability
و شاید مهم‌ترین سؤال این باشد:

اگر Cache و Database با هم اختلاف داشتند، سیستم من دقیقاً چه رفتاری باید داشته باشد؟

اگر جواب این سؤال را قبل از پیاده‌سازی ندانید، احتمالاً بعداً در Production جوابش را پیدا خواهید کرد! 😄

🔖هشتگ‌ها:
#Caching #Redis #CacheConsistency #CacheAside #SystemDesign #DotNet