0

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?
2
  • Is your API already designed for cacheability? GET requests for cacheable resources? Cache-control headers? Etags to enable conditional requests (If-none-match)? Adding a caching proxy like Cloudflare will do very little otherwise, but being able to provide etags might already require cache-like components on your backend.
    – amon
    May 25 at 21:56
  • Not yet, but I plan to do so, can you point me to a good source with Etags? I don't completely understand that concept. And also do you know how to implement such things?
    – godzsa
    May 25 at 22:53
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).

0

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.

5
  • The CMS will be the source of truth for a lot of content. The same app might call it for multiple different contents (menu items, ads, banners, etc. etc.). Now if it gets too many users requests, that it is not able to handle I don't want the whole system to go down, so I want to divide the load by introducing proxy services that are easy to scale horizontally and which cache the data so we don't need to call the CMS (and in the end the DB) for each user sent request because that does not make sense (data is not changing too often). I thought an alternative could be introducing CDN instead,
    – godzsa
    May 25 at 22:15
  • a cdn may help reduce the load on your servers, if you can separate out the dynamic content from the static. BUt you would be better off sorting out why your CMS is slow and ensuring it can scale and failover
    – Ewan
    May 25 at 22:24
  • It is not slow, but as of now I don't have any measures to handle production scale load, these are some preparations/countermeasures to make sure I can handle the load. I have a db which is a bottleneck, I cannot pour 50-100k request per sec on it, also it would be pretty dumb as the data changes maybe once or twice a day. My question if I think about it is basically would it make sense to do this on the service itseld, separate it out to proxy services or CDN, or a combination of these.
    – godzsa
    May 25 at 22:40
  • 2
    if the site is basically static and only changes each day, then output caching on your web server will solve your problem immediately. a CDN basically does the same thing, but at remote sites. You have to be careful you don't have some mini dynamic thing on the page, like the users name in the header or a shopping basket or something else which is generated server side
    – Ewan
    May 25 at 22:44
  • Thanks for the advice! :)
    – godzsa
    May 25 at 22:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.