Same menu. 200 customers. One unnecessary database hit every single time.
A few weeks ago I got a call from the owner of JSL Café and Games, Pune. A café plus gaming zone. Good vibes, good coffee. I had built their website.
He said — "Vivek, I heard that the more my customers open the website, the more requests go to the database. And more requests means more charges. My menu doesn't even change till tomorrow morning. Is there a way to stop paying for the same answer 200 times a day?"
I paused for a second. Not because I didn't know the answer.
-Because I was impressed. A café owner - not a developer - understood something that half the junior devs I know don't think about yet.
He was right.
Every customer walking into JSL, opening the menu on their phone my backend was hitting the database every single time. Fetching the same French Fries Price.
200 customers. 200 database calls. Same answer every time.
That is not just wasteful. That is expensive. And at scale that is how systems crash.
I told him — yes. There is a way.
It is called Caching.
What is Caching?
Caching means storing the result of an expensive operation so you don't have to fetch data from the DB again.
Think of it like this — instead of going to the kitchen every time a customer asks for the menu, you put a printed copy on every table. Same information. Zero trips to the kitchen.
Your database is the kitchen. The cache is the printed menu on the table.
4 Types of Caching
Browser Cache- Your browser saves files locally after the first visit. Next time you open the same site it loads from your device, not the server.
Server-Side Cache- The server stores frequently requested data in memory using tools like Redis. Instead of hitting the database it returns the stored answer instantly.
Database Cache- The database remembers results of recent queries. If the same query runs again it skips reprocessing and returns the saved result.
CDN Cache- A Content Delivery Network stores your static files across global servers. A user in Delhi gets your Mumbai-hosted image from a Delhi server faster and cheaper.
4 Caching Strategies
Cache Aside - Lazy Loading App checks cache first. Data is there return it. Not there fetch from database and store it for next time. Best for read-heavy apps like JSL's menu.
Write Through- Every time data is written to the database it is also written to the cache simultaneously. Always fresh. Slightly slower writes.
Write Back- Data is written to cache first. Database is updated later in the background. Fast writes. Risky if cache crashes before the database update happens.
Write-Around- Data is written directly to the database, completely bypassing the cache. The cache is only populated when the data is subsequently read.
What I actually used for JSL
Cache Aside with server-side caching.
Menu loads from cache. Cache refreshes every 24 hours when the owner updates the menu. Database gets called exactly once per day instead of 200 times.
His bill dropped. His site got faster. He was happy.
That is what one concept can do for a real client
Today's Opportunity -
*Google Cloud Rapid Agent Hackathon - *
https://rapid-agent.devpost.com/
Deadline Jun 12, 2026 @ 2:30am - check tonight and register before you sleep.
Still building. --Vivek
If this helped you, forward it to one developer who is still sleeping on caching.
Agency -- coderiva.in | insta -- @vivekkumar5829
Top comments (0)