Caching, while being a technique that many developers are familiar with, isn’t always straight forward and it’s usage is far from being a rule written in stone.
This topic came to me when recently a friend asked me what would be the best way to cache database responses, as he was afraid of running into performance issues in production. What I replied wasn’t exactly the response he was expecting. Beware in advance that regarding this topic, there are no absolute truths, I’m well aware of that, picture this as my lessons learned.
Over time, I learned a few things about caching:
- you will have to deal with cache invalidation of stale data
- your application will probably die if your caching has some problem
- often, and depending on the situation, when cache expires, you will have huge load spikes
- caching is often messy
Please notice that it’s not my intent to convince you not to do caching, but I do advise you to keep this in mind:
- ensure your architecture is horizontally scalable from the first drafts
- don’t include any form of cache in your architecture, cache should be seen as an add-on, not a core feature
- find the balance between optimizing your code and investing too much time on it
- perform load and stress tests without any forms of cache to get some numbers
- determine how much machine power you need to cope with expected usage
- provision at least 25% more to be on the safe side
- get as much of those machine as your budget will allow
Now that your application is sane, perhaps you can consider some nice “hacks” to boost performance and sleep well at night without getting called at 3:30 AM because your servers just died on a load spike. Go ahead and add some form of caching layer, but do it wisely. If your implementation has been taken good care, I don’t expect this to be such a big effort.
PS: Obviously, this can’t be taken so strictly. As with any rule in general, some sensitivity is expected according to the practical situation and you are allowed to be flexible.
