DSA & System Design
All the parts

Build · Remember it

Cache

How do I make repeated requests faster and lighter on my database?

What it is

A cache keeps a copy of an answer somewhere fast, so the next person who asks gets it without redoing the slow work. Most caches live in memory, so reads are very quick, and each copy has an expiry time so it does not go stale forever. You always have to decide how long a stale answer is acceptable.

It is a sticky note on your monitor: you glance at it instead of walking to the filing room, and you throw it away when it is out of date.

Add it when The same expensive read happens again and again, and measuring shows it is slow or costly.

It can wait when Your app is small and fast already. A cache adds a second place where data can be wrong.

1 Which one should I pick?

Answer what you can. The ranking updates as you go, and you can ignore it if you disagree.

Where does your app run?
What are you caching?
What matters most right now?

Most people start with

2 Side by side

Three pips is strong, one is weak. Pick a row to read about it below.

OptionQuick to set upCheap while smallEasy to leaveRoom to growPrice
Free to run yourself; managed ones charge for size and hours
Free tier, then pay per request
Free to run; managed versions charge for size
Free; it uses your app's memory
Free; part of the web and your CDN

3 Look closer, then wire it in

Open source

Redis (self-run or ElastiCache)

A very fast in-memory store for cached answers, counters and sessions.

Pick it when You run long-lived servers and want one shared cache with rich data types.

Skip it if You are on serverless and do not want to manage connections and a server.

  • Extremely fast and very widely used
  • Counters, lists, sets and rate limits built in
  • Runs anywhere, including managed AWS ElastiCache
  • You size, secure and monitor it
  • Data is in memory, so it costs more than disk
Quick to set up
Cheap while small
Easy to leave
Room to grow

PriceFree to run yourself; managed ones charge for size and hours

How to connect it

  1. Run Redis, or create a managed one, and keep it on a private network.
  2. Set a password and never expose its port to the internet.
  3. Install a client and create one connection that you reuse.
  4. Store values with an expiry (TTL).
Put these in your .env file
  • REDIS_URL
redis.ts
import { createClient } from "redis";

export const redis = createClient({ url: process.env.REDIS_URL });
await redis.connect();

await redis.set("user:42", JSON.stringify(user), { EX: 300 }); // expires in 5 min
const hit = await redis.get("user:42");

4 Watch it work

Press play, or step through one message at a time.

Press Play to watch it run · 4 steps

Your app looks in the cache first. Only on a miss does it do the slow work, and then it saves the answer.

Cache-aside: hit and missYour app looks in the cache first. Only on a miss does it do the slow work, and then it saves the answer.Get product 7GET product:7alt [Hit: the cache has it]Here is the saved copyFast answer
  • Client
  • Service
  • Cache
  • Database
Text description
  1. Browser → Your app: Get product 7
  2. Your app → Cache: GET product:7
  3. Cache replies to Your app: Here is the saved copy
  4. Your app replies to Browser: Fast answer

5 Mistakes to skip

  • Saving to the cache with no expiry.

    Always set a time to live, so stale data fixes itself.

  • Caching private data under a shared key.

    Put the user id in the key, or do not cache it. Never let one user see another's data.

  • Adding a cache before measuring.

    Find the slow request first. Often an index on the database fixes it with nothing new to run.

See where it sits in a whole app

The stack builder draws your product with cache in it and animates a request through it.

Open the stack builder

Works closely with