Caching

 Caching reduces latency and speeds up a system. We will store data in a different location than where it was originally being accessed so that it will be accessed faster. 

When do we need caching?

1) We have clients repeating the same network requests. For example, Graphql can cache data on the client side so that we can avoid fetching the same requests repeatedly or We can cache static data like css/html on the client's browser on first load.

2) We perform computationally expensive operations. We can cache it to avoid doing the same operation and speed up the system.

3) We have multiple servers accessing the same data from a database. We can avoid this by having the servers fetch from a cache instead of the database or maybe we can setup the cache on the server side.

Caching when writing:

When you are making write or edit requests, you may run into a problem with having 2 sources of truth. For example, you may have a cache of the data on the server as well as having it on the database itself. When you try to make an edit of the data, how do you handle having 2 sources of truth?

1) write-through cache: When you make an edit, your system will write that data on the cache and the database in the same operation. This way the cache and the database will always be in sync. The downside to this is obviously it is one more step that slows down the system.

2) write-back cache: only updates the cache. This makes the data out of sync but the server will asynchronously update the data in some interval. The downside is possible data loss if the cache is somehow lost. Another downside may be that clients may be getting out of date data from cache.

Dealing with stale cache data(depending on if the data is important enough to be up to date):

1) We can move the cache from the individual server and move it to a cache server like Redis so that all of the servers will be up to date.

2) evictions policies - LRU (least recently used). LFU(Least frequently used)