Read on Twitter
Caching is a simple idea but difficult to implement.
Use too much caching; you'll be working with stale data. Not enough caching, your application gets slow.
Here're some things I've learned about caching.
Share your lessons learned too
Use too much caching; you'll be working with stale data. Not enough caching, your application gets slow.
Here're some things I've learned about caching.
Share your lessons learned too
Just like every piece of tech on a project, gather as much evidence as you can to help you decide if you need to cache something.
Bottlenecks are usually a good place to start but always look for other low-hanging fruit to improve performance first.
Bottlenecks are usually a good place to start but always look for other low-hanging fruit to improve performance first.
Whenever you add a cache layer, you make the system more complicated.
If you must add a cache, start small, analyze the data and see how to improve it or remove it if it doesn't work. If at all possible, use what's already available to you like HTTP headers.
If you must add a cache, start small, analyze the data and see how to improve it or remove it if it doesn't work. If at all possible, use what's already available to you like HTTP headers.
Always, and I do mean always, add metrics for hits and misses (when data is found or not) in the cache. Keep an eye on these metrics; they will tell you if your strategy is working, if you need to change strategies or if you don't need caching at all.
Take your time evaluating caching strategies. You could find the same type of cache the team's been using doesn't apply to every services/requests/data
There're many places where you can add cache to an application, from the end-user POV to the database and everything in between
There're many places where you can add cache to an application, from the end-user POV to the database and everything in between
You can cache the same data you return, sometimes you cache an aggregation of data or a specific view of the data you need to return.
If there is only one use case for the data but you need to cache it in a different format, maybe what you need is a data schema migration.
If there is only one use case for the data but you need to cache it in a different format, maybe what you need is a data schema migration.
Whatever your cache strategy is. Always take into account availability.
Is your application going to stop working if your cache goes down?
How much slower is your application going to be if the cache goes down?
Is your application going to stop working if your cache goes down?
How much slower is your application going to be if the cache goes down?
Always set a time to live (TTL) when you start implementing a caching strategy. Figuring out the correct way to invalidate cached data is difficult, and using a TTL will prevent you from having stale data hang around for too long in the beginning.
Whatever data you're caching, it will change over time. Make it easy to modify/extend the cached data format.
Thanks for reading 
Follow me for weekly threads on the human and technical side of Software.
Be Kind.
Follow me for weekly threads on the human and technical side of Software.
Be Kind.
