One thing I completely underestimated while building my e-commerce application was caching.
Initially, every user action looked like this:
Browser → API → Database → ResponseIt worked.
Until I started asking:
"Why is the same product being fetched thousands of times?"
That's when I realized caching exists at multiple layers — and every layer solves a different problem.
Avoids downloading the same JavaScript, CSS, and images repeatedly. The cheapest cache is the one you don't have to run — the user's browser handles it for free.
Keeps recently fetched API data in memory, making navigation feel instant while reducing unnecessary API calls. When you click back to a page you visited 30 seconds ago, it renders from memory instead of re-fetching.
Serves static assets from the nearest edge location, reducing latency for users around the world. Someone in Bangalore and someone in Berlin both get the same image — but from a data center a few hundred kilometers away, not from your origin server.
Stores frequently accessed data — products, categories, sessions, OTPs, search suggestions — so the application doesn't keep hitting the database for answers it already has.
A category tree that changes once a day does not need to be rebuilt on every page load.
The source of truth. It should answer the questions that haven't already been answered by the layers above.
When someone actually buys something, the database is where the record lives. When they're just browsing, it shouldn't be touched.
It wasn't learning Redis or React Query.
It was understanding where data should come from.
If every request reaches your database, your architecture isn't scaling.
If everything is cached forever, your users eventually see stale data — and stale data in an e-commerce cart is worse than a slow page.
Engineering is finding the right balance between:
- Freshness — how recent does this data need to be?
- Performance — how fast does it need to arrive?
- Complexity — what's the cost of maintaining this cache?
- Cost — what does it take to run?
A cache is a bet that the answer you already have is still correct. Sometimes that bet pays off. Sometimes it doesn't. The skill is knowing which is which.
The more I build, the more I realize that performance isn't about making the database faster.
Sometimes it's about not asking the database at all.
And that shift in thinking — from "how do I make this query faster" to "why is this query happening at all" — is where the real engineering starts.
