Cache aside vs Read through

Cache aside: app checks cache and fetches from DB on miss then updates cache
Read through: app checks cache, the cache will automatically fetch from the DB if missing
The difference between the 2 above, is what is fetching from the DB on cache miss. Either the app or the cache system itself, but the principle is the same.
Benefit of readthrough is that the app code only needs to fetch from the cache and the cache logic manages what happens on miss.

If you need to invalidate the cache, you can manually remove the key.
If consistency matters, you can invalidate on DB write so that the next read triggers a refresh from DB.

Write through vs Write back

Write through: app writes to the cache and then to the DB
Write behind (or back): app writes to the cache and queues an update to the DB for later
The main difference is the data consistency. Write behind is eventually consistent, but faster.

From Google

Strategy	How it Works	Read Speed	Write Speed	Data Consistency	Best Used For
Cache-Aside	The application manually checks the cache, fetches from the database on a miss, and updates the cache.	Fast (on hit)	Fast	Eventual (requires app manual eviction)	General purpose, read-heavy workloads with unpredictable query patterns
Read-Through	The application asks the cache for data, and the cache automatically pulls it from the database if missing.	Fast (on hit)	Normal	Eventual (managed by cache provider)	Read-heavy workloads where you want to keep cache logic out of the app code
Write-Through	The application writes data to the cache, and the cache immediately saves it to the database before finishing.	Fast	Slow	Strong (cache and DB update together)	Applications that cannot tolerate stale data (e.g., banking ledger balances)
Write-Behind	The application writes data to the cache, which acknowledges it instantly and saves to the database later in batches.	Fast	Fastest	Eventual (DB updates lag behind cache)	Write-heavy workloads with high bursts (e.g., IoT data streams, real-time gaming scores)

Key Takeaways & Trade-offs

Application vs. Cache Responsibility: Cache-Aside requires you to write the fallback logic inside your application code. Read-Through abstracts this away, moving the database fetching responsibility entirely to the caching infrastructure.
The Write Speed vs. Data Safety Dilemma: Write-Through guarantees strong consistency and zero data loss, but it penalizes application write performance with dual network round-trips. Write-Behind provides maximum speed by writing to memory first, but you risk losing data if the cache crashes before syncing to the database.
Memory Optimization: Patterns like Cache-Aside and Read-Through only load data on demand, keeping memory costs low. Write-intensive patterns can cause cache churn by filling memory with data that may never be read again.