Why caching isn’t always the best solution — Part I

As a developer, you’re facing a lot of constraints, your boss wants to have better money returns and your colleagues want an application that goes fast, easy to maintain and probably, that’s capable of making coffee.
To achieve this, you can do a lot of things but as passed the point of non return when it comes to “quality” and “performances tests” assurance, your application is at his top level and you’re wondering :

“ What if I had a cache layer ?”

Well, probably, caching the whole application isn’t probably the solution and I’m gonna tell you why.
Earlier this year, I’ve discussed with a friend about his programming habit and the constraints who was fixed by his technical boss, he told me something I can’t believe earing in 2017 :

“Well, that’s simple, my boss told me that an application doesn’t need to be good and easy to maintain as long as you have cache …”

After a good breath, I told him this thing :

“If your boss is telling you this, that’s probably because he sucks as a developer.”

Yeah, I know, that’s probably hard to ear but if you think that cache can help you resolve every performances issue of your application, it’s sad to say this but you’re probably a bad developer and an even worst architect.
First, what is cache ?

At it’s simple approach, cache allow you to store data or request (HTTP or other !) into a big array, this way, every time that a new user ask for a resource or for a page, your system gonna take look into this array and check if the request is cached, if it is, the system’s gonna return the cached response and your visitor gonna receive a fastest response than if it’s coming from your application.

In the details, the caching process and architecture is a little bit harder to handle but if you understand this simple principle, you’re good to go.

Ok, now that you have a basic understanding of the cache approach, let’s discuss about his pros and cons.

First, the pros :

• Fastest response.
• Better I/O and network usage.
• Lower network usage on mobile device.

Then the cons :

• Harder debugging (i’m gonna talk about this later).
• Need to invalidate the cache
• Server constraints

As you can see, the cache doesn’t have a lot of cons, the problem is :

“Is the cache the right solution for your application ?”

If you look at the pros, yes, that can lead you to use a cache and configure it but before installing something, let’s think about your code.

If you think at your code like a whole, probably it probably look good enough to be deployed in production but what if you take a better look and look closely at the internal logic ?

Ah, I know, this can seem strange but that’s the truth, if you take a deeper look into your code, you’re probably about throwing your computer by the window and you know why ?

I’m about too.

Yes, this can seems surprising but the true goal of the cache is to optimize your execution time but in order to optimize this time, YOUR code needs to be perfect (or at least, pretty good) and prepared to handle a lot of calls, as a backend developer, I always tell people to forget about cache, NoSQL or others things like that in order to focus on the main problem : The code.

You need to understand that your code represent the first block of logic who’s called when a request is send to your application (even if you’re on mobile), there’s always a code who handle the request, this way, you have the full control over the execution and the performances of this code ! I know, you’re about to tell me that if I develop using a web framework or a mobile framework, there’s a lot of things that I can’t control …
In fact, not really.

As a developer, you’ve learned about using the language in order to build something but what about optimizing it ?

Ahah, you having a hard time and I can see from here the sweat that run through your face, like me when I started using PHP, you’re developing a lot of things without thinking about the optimisation part of the process and then when the project is about to be deployed in production, you’re thinking about the performances and code quality when suddenly …

I know this feeling, that’s why we’re here, surprisingly, your code is not good enough and the production isn’t ready to handle this type of “hard” code, so, like a lot of developer, you suggest to using cache then … Bam, very bad idea.

Stop thinking about cache !

It’s exactly this type of reaction which lead great project into a really hard time when it comes to refactorization and evolution, in fact, cache is probably a good idea if your code looks like the one whose runing on Google or Facebook (translation : A code who is required millions of times per hours/seconds and which need to be really fast and reactive) but before this, you’re not Google or Facebook and you need to ensure that the final user isn’t a beta tester, this way, it’s important to understand that the cache lead to a lower quality demand on your code and this lead to performances issues and for reasons !

If you decide to use a cache even before verifying the quality of your code, you play with the execution of this one and that can lead to lower performances then, back again, thinking about adding a cache.

Like you know, if an user wait more than 3 seconds on a webpage, he quit her, same thing goes for mobile application, I’m a reactive person, I don’t like to wait when I launch a application, think about user experience and not cache !

The cache helps you to think about “server optimization” but the server run your code so the first things to look is your code ! In order to optimize the usage of a cache layer, you need to optimize the code layer, this way, the cache act like a gift paper and make the whole code way better, I know, this can seem strange but if you apply this logic, your code will increase in quality and in performances, after this, try to add a cache, just for measuring the gains then see if it works like expected, if not, take a look at your code then optimize him !

The next part gonna talk about how to optimize your code for production and how verify the quality/performances, see you next time and have a great day !