Taking load off of Rest API with Cloudflare Cache?

Question

I have a server running on AWS which serves data, that is not changing too often (think about a CMS system) to multiple clients.

This service is critical for most of the client apps, thus I want to take some load off of it. I wanted to introduce another service between the clients and the server with a (Redis) cache with the intention that this way the middle layer will mostly serve cached data and only call my "critical" Rest Api when the cache is invalidated (e.g. by the critical server itself).

However, I was thinking why would I keep up a server just to act as a caching layer or middleman when I could use a CDN like Cloudflare to do this?

1. Is my approach a sufficient one to protect my "critical" service?
2. Do you have a better alternative?
3. How do I set this up on Cloudflare, and is there a way my "critical" server can call Cloudflare to flush the cache when the data is updated?

Answer 1

This all depends on how quickly you need changes to propagate upstream from your protected service to your clients. Content delivery networks all have some latency between telling their services to expire their cache and those servers requesting updated data. Since a CDN is distributed around the world, different regions could experience different latency times.

If expiring the cache is not time-sensitive or the time it takes to inform all the CDN servers of content updates fits your needs, then you would be using a CDN for its intended purpose.

Creating a middle service to do the caching is basically what a CDN does, but on a much smaller scale. The only advantage here is that you would have full control over updates. You could set up a more proactive approach to content updates. Your protected service could send a message to a message bus informing the cache server which data has changed. The cache server could decide to simply expire the cache or request new data before the next request arrives to the cache server. Honestly this is probably something a CDN can do as well.

Just be aware that frequently updated data could still result in a lot of traffic to your protected service, so it is a balancing act.

In order to leverage the ease with which a CDN can scale, and the durability it provides by distributing the workload across the world, I would start out with the CDN first. As an added benefit, a CDN is also a good layer of insulation against distributed denial of service attacks, but probably isn't the main reason to go with a CDN (unless, of course, you frequently get DDOS'd).

Answer 2

I think you are mixing up ideas here.

If you want to make sure your API is up 99.99999% of the time, then you have to look at removing any single points of failure. Just spin up more copies of your API, make sure your database can scale put things in multiple availability zones etc.

Adding a cache doesn't help you here, its just another thing that's used on every call and might break

If you want to reduce the cost, or scale your API so that it can serve more requests then you can reduce its CPU time/network use etc by implementing a cache around bits that you know intensively use those resources.

So say you have a shared database which has to do an intensive query on every call, you can cache the results of the call in a reddis cache to avoid making the call so often. Saving CPU

If your bandwidth is running low, or the latency on requests from far away places is a problem, you can use cloudflare or similar to optimise the network traffic.

I see people throwing in a random cache "to make things faster". Most of the time its the wrong choice.