Two Hard Things: caching bugs · Intro
Your request passes five caches
Browser, CDN, your app's memory, Redis, and Postgres' own buffer cache. Every layer is a copy, and every copy can go stale. Ask three questions of any cache: who can see it, how long is it trusted, and who deletes it when the truth changes? If you can't answer the third, you have a bug with a timer.
Comment below: How many cache layers does your app have?
Two Hard Things: a series on the caching bugs you already ship, and how to fix them. "There are only two hard things in computer science: cache invalidation and naming things." (Phil Karlton) All code is real TypeScript on Node, typechecked before it went on screen, and every claim was reproduced against real Redis and Postgres.
Transcript
Your request passes five caches before it reaches your database. The browser, the request never even leaves the device. The CDN, a copy on a server near the user. Your app's memory, nanoseconds, but one copy per server. Redis, one shared copy under a millisecond away. And even Postgres keeps hot pages in RAM. Every layer is a copy. Every copy you add can go stale. So, ask three questions of any cache. Who can see it? One user or everyone? How long is it trusted? And who deletes it when the truth changes? If you can't answer the third one, you don't have a cache. You have a bug with a timer. Best practice, draw your cache layers before you add another one. Every part of this series is a bug in one of these layers. Start at part one. How many layers does your app have?
