Y

What caching actually is

Your database is slow relative to memory. Not slow in an absolute sense — but every time your app needs data, querying a database involves disk reads, connection overhead, and query execution. At low traffic, this is invisible. At high traffic, it becomes the bottleneck.

A cache is a copy of data stored somewhere faster to access than the original source. Usually that means memory — RAM — which is orders of magnitude faster to read from than a disk.

The basic idea: instead of hitting your database every time a user loads your homepage, you compute the result once, store it in memory, and serve that stored copy for the next thousand requests. When the data changes, you update the cache.

That's it. The implementation gets complicated, but the concept doesn't.

Where caches live

There isn't one cache. There are several, layered at different points in the system.

Browser cache — When you visit a website and the logo loads instantly on your second visit, that's your browser serving the image from local storage rather than re-downloading it. Your team controls this with HTTP headers. Costs nothing to implement correctly, and gets ignored more than it should.

CDN cache — A Content Delivery Network stores copies of your static files (images, JS, CSS) on servers physically close to your users. A user in Surabaya hitting a CDN node in Jakarta gets a faster response than hitting your origin server in Singapore. Vercel, Cloudflare, and AWS CloudFront all do this.

Application cache — This is where lives. Your server checks Redis before hitting the database. If the data is there (a "cache hit"), it returns it immediately. If it isn't (a "cache miss"), it queries the database, stores the result in Redis, and returns it. Subsequent requests get the fast path.

Database cache — Databases like Postgres maintain their own internal buffer pool, caching frequently accessed rows in memory. This is mostly automatic, but it's why throwing more RAM at a database often improves performance before you've done anything else.

For most startups, the one that matters most — and the one your team is probably talking about — is the application cache backed by Redis.

The part most founders get wrong

Caching feels like a free lunch. It isn't.

The hard problem is cache invalidation: knowing when to throw away the stored copy and fetch fresh data. Get it wrong in one direction and your users see stale information. Get it wrong in the other and you cache so aggressively that the cache provides no benefit when data changes frequently.

A common failure pattern: a startup caches user profile data for 10 minutes to reduce database load. A user updates their email address. For the next 10 minutes, parts of the app still show the old address. Support tickets arrive. The fix is straightforward — invalidate that cache entry on update — but it requires the engineering team to track every place the cached data is used and make sure writes are coordinated with cache state.

Phil Karlton, one of the original engineers at Netscape, put it bluntly: there are only two hard things in computer science, and cache invalidation is one of them. He wasn't joking.

This doesn't mean caching is dangerous — it means it requires discipline to implement correctly. When your team says "we added caching," it's worth asking: what's our invalidation strategy? If they have a clear answer, good. If they say "it expires every 5 minutes," ask how you handle the window between a write and the expiry.

What this looks like during a traffic spike

GoPay and similar payment products in Indonesia face predictable load spikes — payroll dates, Harbolnas, Lebaran. Without caching, every user checking their balance or transaction history hits the database directly. Under peak load, the database becomes the bottleneck and response times degrade for everyone.

With a well-implemented Redis layer, balance reads that don't need to be real-time serve from memory. The database handles writes and periodic cache refreshes rather than every single read. The result isn't magic — it's arithmetic. Fewer database queries under the same load means the system stays responsive.

The tradeoff: you've now introduced a system that can serve slightly stale data. For a balance display that's 2 seconds behind, most users won't notice or care. For a payment confirmation screen, you wouldn't cache at all. Knowing which data can tolerate staleness and which can't is where the engineering judgment lives. As a founder, understanding this distinction helps you ask the right questions about where your team is drawing those lines.

For a deeper technical breakdown of how Redis fits into your infrastructure, see [→ Read: What Is Software Architecture?] for the broader context.

FAQ

Q: Do we need caching from day one?

A: No. At low traffic, caching adds complexity with minimal benefit. Add it when you have a specific, measured problem — high database CPU, slow page loads under load — not as a precaution. Premature caching is a real source of bugs.

Q: What is Redis and do we need it?

A: Redis is an in-memory data store used almost universally as an application cache. If your team is adding server-side caching, they're almost certainly using Redis. It's fast, well-supported, and has managed hosting options (AWS ElastiCache, Upstash) that remove most of the operational burden.

Q: How do we know if our caching is working?

A: Your team should be tracking cache hit rate — the percentage of requests served from cache rather than the database. A healthy cache hit rate for most applications sits above 80%. Below 50% means either your cache configuration needs work or the data you're caching changes too frequently to benefit from it.

Q: Can caching cause bugs?

A: Yes. Stale data is the most common one. A user makes a change, but the cached version hasn't been invalidated yet, so they see the old state. Good teams think through cache invalidation before shipping, not after the first user complaint.

Q: What's the difference between caching and a CDN?

A: A CDN caches static files (images, JS, CSS) close to the user. An application cache (Redis) stores the output of database queries or computed results on the server. They solve different problems and most production applications use both.

Caching is one of the highest-leverage things an engineering team can add to an application — and one of the easiest to implement badly. If your team is planning to add it, the right question isn't whether to do it. It's whether they've thought through what happens when the cached data is wrong. That conversation will tell you more about your team's engineering maturity than almost anything else.