Skip to main content

Caching Strategies Simulator

Learn caching fundamentals with an interactive simulator. Visualize cache hits, misses, eviction policies (LRU, LFU, FIFO), and understand write strategies.

Category: Infrastructure

Topics covered: caching, performance, redis, educational, interactive, backend

// simulator

Caching Strategies Simulator

Learn caching fundamentals with an interactive simulator. Visualize cache hits, misses, eviction policies (LRU, LFU, FIFO), and understand write strategies.

Supported byBecome a sponsor
BitriseAtomsizedDigitalOceanDevDojoSMTPfastQuizAPI
Eviction Policy

LRU: Removes the item accessed longest ago

Cache Simulator
Tap to request data:

Green ring = in cache

Your App
-
-
-
-
Cache (1-10ms)
Database(50-200ms)
Request Log
$ Tap an item above...
Stats
0
Hits
0
Misses
0%
Hit Rate
0ms
Total Time
Cache (0/4)

Cache is empty

Why Use Caching?
Without Cache

Every request = slow DB call

With Cache

Repeat requests = instant!

The eviction policy decides what to remove when cache is full.

Understanding Caching Strategies

Eviction Policies

  • LRU (Least Recently Used): Evicts items not accessed recently. Most common in practice.
  • LFU (Least Frequently Used): Evicts items accessed least often. Great for identifying hot data.
  • FIFO (First In, First Out): Simple queue-based approach, evicts oldest items first.
  • TTL (Time To Live): Evicts items based on expiration time. Common for sessions.

Write Strategies

  • Write-Through: Writes to cache and database simultaneously. Strong consistency but higher latency.
  • Write-Back: Writes to cache first, async to database. Better performance but risk of data loss.
  • Write-Around: Writes directly to database, bypasses cache. Reduces cache pollution.

Key concepts

  • Hit rate: Percentage of requests served from cache (higher is better).
  • Cache size: Balance between memory usage and hit rate.
  • Hot data: Frequently accessed items that benefit most from caching.
  • Cache invalidation: One of the hardest problems in computer science.

Overview

A cache keeps a small copy of data that is expensive to fetch, so most requests skip the slow path. This simulator puts a cache with room for four items in front of a database and lets you request data such as a user profile, a product list, settings, a dashboard, messages or analytics. Each request either hits the cache and returns immediately, or misses, fetches from the database, stores the result and returns it, and the hit rate and the time saved update as you go. When the cache is full, it has to evict something, and you can choose how: LRU removes the item used least recently, FIFO removes the oldest item, and LFU removes the item used least often. Requesting the same keys in different patterns shows how the policies differ, for example how one scan of rarely used items can push frequently used ones out under LRU but not under LFU. The explanation below the simulator also covers write strategies, write-through, write-back and write-around, and why every cache needs an expiry or invalidation plan.

Try this

  1. With the LRU policy, request five different items and watch which one is evicted when the cache is full.
  2. Select LFU first, request the same item several times, then request enough different items to fill the cache and see which entries survive.
  3. Compare the hit rate and the time saved after the same sequence of requests under LRU, FIFO and LFU.

Frequently asked questions

What is the difference between LRU and LFU?
LRU (least recently used) evicts the item that has gone longest without being accessed. LFU (least frequently used) evicts the item with the fewest accesses, so popular items survive a burst of one-off requests.
What is the cache-aside pattern?
The application checks the cache first, and on a miss reads from the database and writes the result into the cache. It is the most common pattern with Redis or Memcached.
What is the difference between write-through and write-back?
Write-through writes to the cache and the database at the same time, which is safe but slower. Write-back writes to the cache first and to the database later, which is faster but can lose data if the cache fails.

Try next

Sponsored
Carbon Ads
$ cd /games
// share