To cache or not?

(This post has been originally written in 13 DEC 2014).

Buffers and caches are everywhere. A trash bin can be seen as a buffer; A paper notebook can be seen as your external memory cache. Even the air, acts as a buffer of water (see the clouds? – I mean, the real ones; when it can’t handle anymore, it drains the ‘water’ buffer, and it well – rains)
The same thing happens with all of our digital data. Every bit of it will have a variable value over time, and it may or not make sense to store depending on which point in time you look at it. But not only it matters how long you store it, as well as how often do you need or can exchange it with other systems for which it is useful.
In some cases, buffering/caching is not worth it; In others, it’s a requirement. However, in vast majority of cases, the ideal solutions sits neither in one or the other end of the spectrum, but instead somewhere in between.
See, your pictures might get more valued over time, at the same time that you’ll want to get rid of your bank statement as they get older.
As a system designer, one has to find the right balance whether temporary storage is worth it or not, if yes for what and for how long.
The more the “real time” the requirement is, the less buffers or caches matter. The less the synchronisation frequency or “buffer drain” and the longer the validity of such thing is, the more a caching/buffering solution becomes valuable.
When it comes to data transfer, we can make the following projection / estimation :

By hitting the right balance, you save resources (processing + storage), while not loosing important information.
In reality, this has been way overlooked and as system developers, we’ve been often comfortable with: well, no network, no go, sorry pal, and synchronization systems were only tasks for the “big guys” with deep pockets.
Indeed for years, creating caching/buffering systems has been a lot of work (let alone do it hybrid – the in between cases). But today I see this picture changing with the introduction systems such as Couchbase mobile, or CouchDB, Realm, etc.
I will now explore using this couchbase mobile to create an invisible layer for the common REST Request-Response model found in mobile applications.
The funny thing is, it really happened that while developing the app, my internet connection went down, and I no longer could make my usual http requests to the server. So why not use Couchbase Mobile as a transparent caching layer for all the API calls that are relevant in our time-validity spectrum?
If the results are positive, I’ll suggest integrating the functionality directly in the framework so that one can quickly develop the close-to-perfect hybrid layer of data exchange / caching.
Edit: The experimental project was made and proven to work. Check my github for “HTTPSmartCache” project.