Cache more, optimize less: a primer on read-heavy data access patterns
You can spend a year tuning queries, or you can cache the right things and move on with your life.
Engineers love query optimization. It is craftsmanship. It is fun. It is also the wrong battle for most applications.
The two questions that matter
- How often does this data actually change?
- How often does it actually get read?
If a piece of data is read 1,000 times for every 1 write, no amount of query tuning is the right answer. Cache it. The query that gets run zero times is infinitely fast.
The trap of "we'll cache it later"
"Later" never arrives. Caching gets bolted on when the database is already on fire. By then, the cost of getting invalidation right is so high that teams settle for half-correct solutions and ship bugs. The right time to design for caching is when you design the schema.
redfly is built around that assumption. The cache is not an afterthought. It is generated alongside the data access layer, from the same schema. By the time the first endpoint exists, the cache exists.