Wiki.Quizz.vn

User Tools

Site Tools

Trace: • phongledev • interview
skills:cache

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
skills:cache [2026/05/26 06:56] – phong2018skills:cache [2026/05/26 06:58] (current) – [Sequence Diagram] phong2018
Line 1: Line 1:
-Cache Invalidation Patterns in Real Production Systems+====== Cache Invalidation Patterns in Real Production Systems ======
  
 ===== Overview ===== ===== Overview =====
Line 7: Line 7:
 In real production systems, the hardest problem is: In real production systems, the hardest problem is:
  
-Keeping cache correct under concurrency and distributed timing issues.+Handling concurrency and distributed timing while keeping cache consistent with DB.
  
-Most systems use hybrid strategies, not a single pattern.+Most systems use a combination of patterns, not a single approach.
  
-1. Cache-Aside (Most Common Pattern)+===== 1. Cache-Aside (Most Common Pattern) =====
  
-===== Concept =====+==== Concept ====
  
-Application manages cache manually. Cache is disposable; DB is source of truth.+Application manages cache manually. Cache is a read-through optimization layer, DB is the source of truth.
  
-===== Read Flow =====+==== Read Flow ====
  
 <code> Client → Application → Cache ↓ miss Database → Cache → Response </code> <code> Client → Application → Cache ↓ miss Database → Cache → Response </code>
  
-===== Write Flow =====+==== Write Flow ====
  
 <code> Client → Application → Database update → delete cache key </code> <code> Client → Application → Database update → delete cache key </code>
  
-===== Where it is used =====+==== Where it is used ====
  
-E-commerce systems +Microservices systems 
-Microservices APIs +E-commerce platforms 
-Social platforms+Social applications
  
-===== Pros =====+==== Pros ====
  
 Simple Simple
 Safe Safe
 Easy to debug Easy to debug
 +Flexible
  
-===== Cons =====+==== Cons ====
  
-First read after miss is slow+Cache miss causes DB hit
 Small stale window possible Small stale window possible
-2. Write-Through Cache 
  
-===== Concept =====+===== 2. Write-Through Cache ===== 
 + 
 +==== Concept ====
  
 Write goes through cache first, then DB. Write goes through cache first, then DB.
  
-===== Flow =====+==== Flow ====
  
 <code> Client → Cache → Database </code> <code> Client → Cache → Database </code>
  
-===== Pros =====+==== Pros ====
  
 Strong consistency Strong consistency
 No stale cache No stale cache
  
-===== Cons =====+==== Cons ====
  
 Slower writes Slower writes
 Higher cost Higher cost
-3. Write-Behind Cache 
  
-===== Concept =====+===== 3. Write-Behind Cache ===== 
 + 
 +==== Concept ====
  
 Write goes to cache first, DB updated asynchronously. Write goes to cache first, DB updated asynchronously.
  
-===== Flow =====+==== Flow ====
  
 <code> Client → Cache (ACK) ↓ async Database </code> <code> Client → Cache (ACK) ↓ async Database </code>
  
-===== Pros =====+==== Pros ====
  
 Very fast writes Very fast writes
 High throughput High throughput
  
-===== Cons =====+==== Cons ====
  
 Risk of data loss Risk of data loss
 Complex recovery Complex recovery
-4. TTL-Based Invalidation 
  
-===== Concept =====+===== 4. TTL-Based Invalidation ===== 
 + 
 +==== Concept ====
  
 Cache expires automatically after time. Cache expires automatically after time.
  
-===== Example =====+==== Example ====
  
 <code> user:123 → TTL = 5 minutes </code> <code> user:123 → TTL = 5 minutes </code>
  
-===== Pros =====+==== Pros ====
  
 Simple Simple
-Safe fallback mechanism+Safe fallback
  
-===== Cons =====+==== Cons ====
  
-Stale data until expiry +Stale data until expiration
-5. Event-Driven Invalidation+
  
-===== Concept =====+===== 5. Event-Driven Invalidation ===== 
 + 
 +==== Concept ====
  
-DB changes trigger events that invalidate cache.+Database changes emit events to invalidate cache.
  
-===== Flow =====+==== Flow ====
  
 <code> Service → Database update → Event (UserUpdated) ↓ Cache Service → delete/update cache </code> <code> Service → Database update → Event (UserUpdated) ↓ Cache Service → delete/update cache </code>
  
-===== Pros =====+==== Pros ====
  
-Decoupled architecture +Decoupled systems 
-Scales well+Scalable
  
-===== Cons =====+==== Cons ====
  
 Eventual consistency Eventual consistency
 Event delay or loss possible Event delay or loss possible
-6. Critical Concept: Update-on-write vs Invalidate-on-write (Concurrency) + 
-🟥 6.1 Update-on-write (RISKY in concurrency)+===== 6. Update-on-write vs Invalidate-on-write ===== 
 + 
 +==== 🟥 6.1 Update-on-write (RISKY under concurrency) ====
  
 ===== Problem ===== ===== Problem =====
  
-When multiple requests update same data concurrently, cache can become inconsistent due to race conditions.+Concurrent updates can cause race conditions between DB and cache.
  
 ===== Scenario ===== ===== Scenario =====
Line 128: Line 135:
 Request B updates value = "B" Request B updates value = "B"
  
-===== Sequence Diagram ===== 
- 
-<code> Client A Go API DB Redis | | | | |---update A--->| | | | |---UPDATE--->| | | |<--OK--------| | | |---SET A------------------->| | | | | 
- 
-Client B Go API DB Redis 
-| | | | 
-|---update B--->| | | 
-| |---UPDATE--->| | 
-| |<--OK--------| | 
-| |---SET B------------------->| 
-</code> 
  
 ===== Problem ===== ===== Problem =====
  
-If timing is reversed:+If execution order is mixed:
  
-DB: A → B (correct) +DB = B 
-Redis: A overwrites B (wrong) +Cache = A ❌
- +
-Result: +
- +
-DB = "B" (correct) +
-Cache = "A" (stale ❌)+
  
 ===== Conclusion ===== ===== Conclusion =====
  
-Update-on-write is unsafe because:+Update-on-write is unsafe due to:
  
-Race condition+Race conditions
 Out-of-order execution Out-of-order execution
-Distributed timing inconsistency +Distributed timing issues 
-🟩 6.2 Invalidate-on-write (SAFE approach)+ 
 +==== 🟩 6.2 Invalidate-on-write (SAFE pattern) ====
  
 ===== Concept ===== ===== Concept =====
Line 165: Line 157:
 Do NOT update cache. Only delete it. Do NOT update cache. Only delete it.
  
-===== Sequence Diagram ===== 
- 
-<code> Client A Go API DB Redis | | | | |---update A--->| | | | |---UPDATE--->| | | |<--OK--------| | | |---DEL cache--------------->| | | | | 
- 
-Client B Go API DB Redis 
-| | | | 
-|---update B--->| | | 
-| |---UPDATE--->| | 
-| |<--OK--------| | 
-| |---DEL cache--------------->| 
-</code> 
  
 ===== Why it is safe ===== ===== Why it is safe =====
  
-Even if requests are out of order: +Only DELETE operations on cache 
- +No stale value can be written
-Cache only gets deleted multiple times +
-No stale value is written into cache+
  
 ===== Read Flow ===== ===== Read Flow =====
  
-<code> Client → Redis (miss) → DB → set cache </code>+<code> Client → Redis (miss) → Database → Set cache </code>
  
 Always consistent with DB. Always consistent with DB.
  
-7. Comparison Table +===== 7. Comparison Table ===== 
-Aspect Update-on-write Invalidate-on-write + 
-Cache operation SET DELETE +^ Aspect ^ Update-on-write ^ Invalidate-on-write ^ 
-Race condition risk ❌ High ✅ Low +| Cache operation | SET | DELETE | 
-Out-of-order issue ❌ Dangerous ❌ Safe +| Race condition risk | ❌ High | ✅ Low | 
-Debug complexity Hard Easy +| Out-of-order updates | ❌ Dangerous | ❌ Harmless | 
-Consistency Fragile Reliable +| Cache correctness | ❌ Fragile | ✅ Reliable | 
-8. Key Insight+| Debug complexity | High | Low | 
 + 
 +===== 8. Key Insight =====
  
 Cache is not the source of truth. Cache is not the source of truth.
  
-DB = truth+DB = source of truth
 Cache = disposable optimization layer Cache = disposable optimization layer
  
 Invalidate-on-write works because: Invalidate-on-write works because:
  
-“Even if cache is wrong, it gets deleted anyway”+Even if cache is wrong, it will be deleted anyway.
  
-9. Production Pattern (Real Systems)+===== 9. Production Pattern =====
  
-Most real systems use:+Most systems use:
  
-<code> WRITE: 1. Update DB 2. Delete Redis key+<code> WRITE: 1. Update Database 2. Delete Cache
  
 READ: READ:
Line 219: Line 200:
 </code> </code>
  
-10. Why update-on-write still exists+===== 10. Why Update-on-write still exists =====
  
-Used only when:+Used only in limited cases:
  
-Simple data (low concurrency) +Simple data 
-Need ultra-fast read-after-write +Low concurrency 
-No complex cache relationships+Ultra-fast read-after-write requirement
  
 Examples: Examples:
Line 232: Line 213:
 Feature flags Feature flags
 Simple counters Simple counters
 +
 +===== 11. Bonus Topics =====
 +
 +Cache stampede problem
 +Mutex / singleflight
 +Request coalescing
 +Kafka-based cache invalidation
 +Outbox pattern for reliability
skills/cache.1779778599.txt.gz · Last modified: by phong2018