Cache
Answers read queries from memory while the hot data fits. Writes pass through and invalidate.
What it does#
The Cache stands for Redis: an in-memory store that answers repeated reads without asking the database.
Place it in front of the Database or Connection Pooler. It answers a share of read queries from memory, its hit ratio, and sends the misses on. Writes pass through and invalidate cached data, so a write-heavy mix lowers the hit ratio.
The hit ratio grows with memory compared to your hot data, which grows with users. A longer TTL raises it and serves more stale reads. A new or restarted Cache starts cold and fills up over time. See cache hit rate and cache-aside.
Two engines are on offer. Redis runs on one main thread and reloads part of its data after a restart. Memcached uses every core and comes back empty.
When to place it#
Place it when reads dominate and the Database CPU is high. The Read Mostly Sandbox shows the symptom. Resize it when the hit ratio falls as users grow.
How it fails#
Cache stampede: the Cache restarts empty, and every miss hits the Database at once. While the Database is overloaded, refills time out and the Cache stays cold. Stampede protection and Cache warming prevent it.
Hot key: one key takes a large share of reads and saturates one shard. Hybrid fan-out lets you split hot keys.
A long TTL serves stale data, which fails reads that need fresh data.
A Cache does not reduce connections: it passes its callers' connections through.
Tips#
Turn on coalescing as soon as you own Stampede protection.
Use Memcached when one Redis thread is the limit.
Rules#
- Each further copy costs 25% more than the one before.
- Selling it refunds 50% of what its last copy cost.
- It has 8 sizes. Each step doubles its capacity and its Burn.
- A new copy starts cold and is slow until it warms up.