Imagine you’ve just noticed your website isn’t coping with loads: it’s slow, users are unhappy, and your metrics suggest there are some issues. If you take these symptoms to an engineer, they’ll suggest you go down one of two routes: scaling up your computing power by buying more servers, or reducing the load by using caches.
Caching might be thought of as storing the results of certain computations so they can be used again. Responses to tasks which tend to be resource-intensive get computed ahead of time, and then you try and store these responses relatively close to the user so they are served faster. This gives the server less work to do, and could save you money by sparing you the mushrooming costs of simply buying extra computing power as your project grows.
There are all sorts of types of cache and ways of caching. If you want to make your website or app faster and more able to cope with increased load, it’s important that you get the specifics of your project across to your team of engineers, and also convey how you intend the project to evolve. Your engineers will then be able to pinpoint any bottlenecks and find the right solutions. To give you a sense of what these technologies can do, and help you keep up your end of a technical conversation, we’re going to tell you about some types of caching and some situations where they’re useful.
Caching Complex Database Requests
This type of caching comes in handy when your website has to repeatedly send the same request for various pieces of related data in a database. This could be an aggregate report generated once a week which you show all your website’s users. There’s no point making your database management system constantly compute the same report all week.
This might also be of use for ratings of users, products, and articles on your website. You can store the results of the computations in the database itself or in the type of store we discuss in the next section.
This kind of caching doesn’t work in cases where every user needs their own set of data or where data always has to be up to date.
Caching Frequently-Used Variables in an In-Memory Data Structure Store
There are a few technologies that can be used for this type of caching, such as Redis or Memcached. These are systems which store information in RAM, making them super-speedy. When are they used?
Well, first and foremost, when you need to store chunks of a website that you show to every user, or a decent percentage of users. As in the previous section, the website might be repeatedly carrying out the same tasks, but in this case, you store not the response you get from the database (i.e. data), but the entirety of the compiled HTML which you’re going to show the user. You can also put elements totally unrelated to the database in this type of memory. For instance, if you have a complicated menu structure generated by a big chunk of code, cache it in RAM and your site or app will be faster.
Caching Web Pages in a Web Cache
Technologies like Varnish or Nginx can do this for you. What does this mean? Basically, it means caching the response you get back from the whole server, i.e. the whole page. Why wouldn’t you do this all the time? Because sometimes, you want to show different users something specific to them. But if you have certain pages which are identical for all users (your homepage, for example), then this one’s for you.
What if most of your content is the same for every user, but you have the odd chunk with user-related data? If you cache a page like this, you can still pass through dynamic requests from this page so that each user is served the dynamic part individually. That’s how some major online stores work: their product pages are cached, but shoppers’ baskets are served dynamically.
What more could you ask for, right? But caching with Varnish or Nginx still involves your server, so there are limits to its usefulness. Are there any alternatives?
This refers to caching the whole page or a specific resource on the page (a CSS file, a JS file, or an image) on special servers located as close as possible to your users. The result is that static resources get served to users at top speed.
If your website puts out mountains of media content, it’s worth thinking about using a CDN. This method also works brilliantly if you use technologies like React, Angular or Vue. These are pretty hefty libraries which should be loaded as fast as possible for server users.
This obviously isn’t an exhaustive list of caching types and approaches to working with high loads. For instance, there are methods like Load balancing or DB sharding which increase your system’s resilience by distributing workloads across servers and changing the way databases are organised. These approaches generally don’t affect the user experience, so tend to interest non-technical managers less than caching. They require considerable investment, unlike methods involving caching, which are simpler to implement. That said, if you are interested in delving into those too, leave a comment for us and we’ll write a new article for you.