Cache-aside

The application reads the cache first and, on a miss, reads the database and fills the cache. It is the most common pattern: the cache only holds what is requested, and a cache failure degrades to slower reads rather than errors.

Where it shows up in real systems

  • In-memory cache

    The hit ratio depends on how much of the working set fits in memory, the TTL and the eviction policy. If the cache goes down or is flushed, every read falls on the database at once: plan for that stampede. Write-behind is fast but loses writes if a node dies without a replica.

    In production: Redis (Amazon ElastiCache, Azure Cache), Valkey, Memcached, Dragonfly

See it break, then fix it

Build an architecture, send it a day of traffic and outages, and learn why it holds or fails. Free to start.

Open the learning path Open the sandbox