> Why Not Redis? I have a single VPS, so I can get by with a simple SQLite database. If I had many instances of my API on separate servers<p>Just to push against this a bit. Redis can be very low memory cost and is very easy to run (I give it 5mb). I have a small single server with a few instances of my API that let's me cache pretty much everything I need.
Read your CDN docs very carefully on how it processes requests. Make sure that your CDN does request coalescing.<p>At my previous job, I became responsible for handling >350,000 requests/second and I dug so deep.
Regarding stale-while-revalidate, the author calculates maximum load like this:
“With the options available on hn.unlurker.com, there are only 10 * 12 * 8 * 2 or 1920 possible combinations, refreshed at most once every 15 seconds”<p>That math works until it doesn’t. If for some reason there’s a greater than 15 second response, the cache will open the floodgate and won’t return any cached response until the cache is full.<p>Similarly, errors need to be accounted for. If the server returns a 500, is it configured to be cached? Is stale-while-error configured so the error state doesn’t take the server down?
> stale-while-revalidate is a relatively recent cache-control option<p>Varnish Cache have supported that since version 4.1, it was released 2015-09-30:<p>> Varnish will now use the stale-while-revalidate defined in RFC5861 to set object grace time.<p><a href="https://varnish-cache.org/docs/trunk/whats-new/changes-4.1.html" rel="nofollow">https://varnish-cache.org/docs/trunk/whats-new/changes-4.1.h...</a>
I've been running a handful of low traffic services on a $10 VPS from DigitalOcean for years. I'm currently in a situation where a thing I've made might blow up, and I had to look into CDNs just in case. It's just static content, but updates once per day (it's a daily logic puzzle).<p>I must admit I had no idea what goes into runnig a CDN. First I had a look at DO's spaces object storage which has CDN support. But it wasn't exactly the right tool for serving a static website apparently, but rather for serving large files. For example I couldn't make it serve css files with the correct mime type without some voodoo, so I had to conclude I wasn't doing the right thing.<p>Then I looked at DO's app platform. But that seemed like an overkill for just sharing some static content. It wants me to rely on an external service like GitHub to reliably serve the content. I already rely on DO, I don't want to additionally rely on something else too. Seems like I could also use DO's docker registry. What? To serve static content on CDN I need to create a whole container running the whole server? And what do I need to take into consideration when I want to update the content once per day simultaneously for all users? It's easy when it's all on my single VPS (with caching disabled for that url) but I actually have no idea what happens with the docker image once it's live on the "app platform". This is getting way more complex than I was hoping for. Should I go back to the spaces solution?<p>Right now I'm in a limbo. On one hand I want to be prepared in case I get lucky and my thing goes "viral". On the other hand my tiny VPS is running on 2% CPU usage with already quite a few users. And if I do get lucky, I should afford doubling my VPS capacity. But what about protection from DDoS? Anything else I should worry about? Why is everyone else using CDN?<p>And I don't even have caching! An article like this puts my problem into shame. I just want to serve a couple of plain web files and I can't choose what I should do. This article really shows how quickly the problem starts ballooning.
My blog is on a totally overprovisioned VPS and I use Cloudflare to cache responses for non-logged-in users. I'm using Mediawiki because I want people to be able to edit it and sometimes it can be extraordinarily slow but with Cloudflare it loads instantly if someone visited it some time recently. I really like Cloudflare's caching control.
I've always wondered if it would be worth the effort to display information to the user to indicate that their request was stale and that they'll need to refresh again? 15s is pretty quick, but how do caching schemes work when users need to know when to use their time refreshing and checking the results. Alternatively, I'd be interested to read about the architecture of a modern always fresh caching scheme.