Member-only story
Caching: Powerful, Risky, and Not Always the First Fix
As a developer, you probably face to this challenge where you feel the code you wrote is running very slow. A lot of slowdowns come from doing the same heavy work over and over again. Picture a billing system: every time a user makes a request, the system might need to fetch the latest prices from another service, the requests can take too long, and the pricing service gets hammered with traffic.
The well-known solution is caching. Instead of calling the pricing service every single time, you fetch the prices once, hold on to them for a short window (say five minutes), and reuse them for all requests in that window. You can keep that cache in memory, or use something like Redis or Memcached if you need multiple servers to share it.
When I was new in system design, I was choosing caching as the best solution for slow operations. Now I learned more and know that caches are tricky because a cache introduces state, and state comes with risks. A cache can serve stale data, get out of sync with the real source, or hide bugs in your system. Susan Wojcicki put it nicely:
“Opportunities — the good ones — are messy, confusing and hard to recognize. They’re risky. They challenge you.”
