Caching — Why Your App Feels Slow (And How to Fix It)
Caching is the single biggest performance win in system design. Let's understand it with real examples — from Instagram feeds to Zomato menus.
What is Caching?
Think about how you use your phone's calculator. If someone asks you "What's 15 × 7?", you calculate it once and remember the answer (105). Next time someone asks the same question, you don't recalculate — you just recall it.
That's caching — storing the result of an expensive operation so you can reuse it later without doing the work again.
Why Does It Matter?
Let's say your app needs to fetch a user's profile from the database. The database query takes 200ms. If 10,000 users request the same popular profile in a minute, that's:
That's a 100x improvement. This is why caching is the #1 performance optimization in system design.
Real-World Example: Instagram Feed
When you open Instagram, your feed loads instantly. But behind the scenes, generating your feed requires:
This is expensive. So Instagram caches your feed. When you open the app, it shows the cached version instantly, then updates in the background.
Types of Caching
1. Browser Cache
Your browser stores images, CSS, and JS files locally. Next time you visit the same website, it loads from your computer instead of downloading again.
Example: When you visit sahilsudan.com a second time, it loads faster because your browser cached the assets.
2. Application Cache (In-Memory)
The server keeps frequently accessed data in RAM using tools like Redis or Memcached.
Example: Zomato caches restaurant menus. The menu doesn't change every second, so why query the database every time?
3. CDN Cache
Content Delivery Networks store your static files (images, videos) on servers worldwide, close to users.
Example: A user in Mumbai gets your website's images from a Mumbai server, not from a US server. Much faster.
4. Database Query Cache
The database itself can cache results of frequent queries.
Cache Invalidation — The Hard Part
"There are only two hard things in Computer Science: cache invalidation and naming things." — Phil Karlton
The tricky part is knowing when to update the cache. If a restaurant changes its menu on Zomato, the cached menu is now stale.
Strategies:
TTL (Time To Live): Cache expires after a set time (e.g., 5 minutes). Simple but not always fresh.
Write-Through: Every time data is updated, the cache is updated too. Always fresh, but slower writes.
Write-Behind: Update the cache immediately, update the database later in the background. Fast but risky if the system crashes.
Cache-Aside (Lazy Loading): App checks cache first. If miss, fetch from DB and store in cache. Most common pattern.
Cache-Aside Pattern (Most Common)
App receives request
Check cache → Found? Return cached data ✅
Not found? Query database
Store result in cache
Return data to user
When NOT to Cache
• Data that changes every second (live stock prices)
• Data that's unique per user and rarely re-accessed
• When consistency is more important than speed (banking transactions)
Key Takeaway
Caching is about trading memory for speed. Store things you use often, close to where you need them. It's the difference between a 2-second page load and a 50ms one.
Every system design interview will ask about caching. Know the patterns, know the trade-offs, and you'll stand out.
Software Engineer at Spense. I write about system design, web development, and fintech — explained simply for students and developers.