# Lets  Explore Distributed Caches

**Writeback cache** : Refers to writing to cache first and then the update gets propagated to db asynchronously from cache

**Write-through**: data is written in cache & DB; I/O completion is confirmed only when data is written in both places

**Write-around:** data is written in DB only; I/O completion is confirmed when data is written in DB

**In Memory Caching** - Save memory cost - For commonly accessed data - Avoid Re-computation - For frequent computation like finding average age - Reduce DB Load - Hit cache before querying DB

**Drawbacks of Cache**

Hardware (SSD) much more expensive than DB - As we store more data on cache, search time increases (counter productive)

**Design** - Database (Infinite information) vs Cache (Relevant information)

**Cache Policy** - Least Recently Used (LRU) - Top entires are recent entries, remove least recently used entries in cache

I**ssue with caches**

\- Extra calls

\- When we couldn’t find entry in cache, we query from database.

\- Threshing - Input and output cache without ever using results

\- Consistency

\- When update DB, we must maintain consistency between cache and DB Where to place the cache - Close to server (in memory)

**Benefit :**

Fast

**Issue** \- Maintaining consistency between memory of different servers, especially for sensitive data such as password - Close to DB (global cache, i.e. Redis)

Benefit - Accurate, Able to scale independently

**Write-through vs Write-back**

**Write-through** - Update cache, before updating DB

Not possible for multiple servers

**Write-back** - Update DB, before updating cache - Issue: Performance - When we update the DB, and we keep updating the cache based on that, much of the data in the cache will be fine and invalidating them will be expensive

**Hybrid** \- Any update first write to cache - After a while, persist entries in bulk to database