Caching strategies

Why do we need caching? It's simple. People don't like loaders*. Moreover, people don't like waiting. So, caching some data to instantly show it next time a user asks for it without requesting the server increases app's UX. Which increases user retention. Which increases app's profit.

I have once stumbled upon a problem related to caching and cache invalidation in a mobile app. My main problem was that I'd never done it before and tried to reinvent the wheel. Luckily, my caching strategy was not so tricky. The cache had an expiration date, so I could invalidate it after a day/week/month, and the app could force an update from the server if needed by the "pull to refresh" thing.

After a while, I've found a talk from a mobile conference about different caching strategies. I'll shortly describe all of them, so you don't need to waste 30 minutes of your precious time watching the video. If you're interested in the theme or feel that something is still unclear after reading the post, then go to YouTube and watch the video (it is not boring at all, I promise).

Thanks to the guy who has even drawn block schemes for every strategy. I'll attach them in the comments.

Okay, let's start.

1. Lazy cache

The most basic one. If user request's some data, we try to find it in cache. If it is there, give it to user. If not - make a request to the server and update the cache with data from successfull response.

Pros:
- easy to implement
- instant data delivery
- cached data is independent of internet connection

Cons:
- no cache invalidation

When to use it:
- apps with immutable data that you should upload once a while like book readers, offline apps, etc.

2. Synchronized cache

The same thing as a previous one, but there are two new steps for invalidation. Local (by expiration date for ex.) and server (by status code 304 NOT MODIFIED for ex.) invalidation. If cache is valid we return data to the user.

Pros:
- faster delivery time for up to date data
- invalidation

Cons:
- dependent of connection

When to use:
- apps with not idempotent data*** where user can't add or edit this data. For example: news and booking apps

3. Write-through cache

The most difficult one to implement. However, the reading process is the same as in synchronized cache. But when we apply some changes, we need to synchronize them with our server database.

Pros:
- faster delivery time for up to date data
- invalidation
- full synchronization with server

Cons:
- dependent of connection
- after failed write we should go back to the initial state
- complex implementation

When to use:
- messenger is a best example

4. LRU cache

It speaks for itself. Least recently used cache is removed when we are out of cache memory, so we can put new piece of data in the cache. However, the invalidation now is in write process. MRU and other algorithms can be used.

Pros:
- instant data delivery
- cached data is independent of internet connection
- customizable invalidation mechanism
- not inflating the size of cache data

Cons:
- complex implementation
- you should be careful with invalidation. For example, you may remove some cached data, that user will need in a second.

When to use:
- apps with heavy content like instagram

* those annoying spinning things, which indicate that we are waiting for data from the server
** if there is no connection, we can't properly invalidate our cache
*** the data may update if you refresh the page

#dev