At the mild end, you could get stale data. Deposit some money and the cache doesn't reflect making you wonder whether the deposit happened or not.
On the worst end, you get this - all users get exposed the most recently requested data.
All this to save... a few kB?
Passing dynamic non-cached requests through a CDN isn’t about saving a few kB for the server (by definition it still has to generate it). It’s about improving end-user performance through things like having edge termination of TLS.
So it’s not so easy to have such a blanket statement as no API requests should go through a CDN. While it’s all too easy to inadvertently turn on the caching of requests.
Err, wouldn't the CDN itself still need to do the same TLS handsake with the end server?
Another reason a no-caching CDN can help is when that CDN has a higher quality connection to the backing service than the user has. A lot of eyeball networks out there might have terrible transit connectivity to the global Internet during peak hours (because that cost money), but generally have high quality settlement-free peering with CDNs. By paying a CDN, you're effectively paying them to provide better Internet connectivity to your users.
All infrastructure ran in us-east-1. A considerable percentage (but not the majority) of their customers were based in Australia, and quite a few of them were complaining about sluggish performance. HTTP/1.1 + TLS meant connection handshake alone took over 5 seconds! Before the first useful bit of content was sent. Add in the additional pain of a web framework that was still splitting assets across multiple asset hosts (to compensate for old browser “feature” that limited the number of concurrent requests to a single domain”). Over 30 seconds of connection setup, some of it in parallels, almost all of it blocking page render because it was for HTML or dependent scripts.
Add in a CDN (no caching) and edge termination meant single-digit millisecond handshakes to a POP in the closest major city. Also had the ability enable HTTP/2 at the edge without needing to change anything else which meant improved connection pooling for clients and less connection setup overhead. Backhaul connection reuse also has the benefit of pooling all requests via a specific POP rather than each individual client. We got rid of the asset host thing while we were at it. Just a CDN, no caching, and a greater than ~30000ms reduction in request times for anyone far from us-east-1!
In fact, I think that the performance gain is not worth the extra complexity for most sites out there. The recent fastly outage, klarna outage, ... all show that CDNs are no silver bullet.
This creates a complete disconnection between whatever TLS handshakes are happening between the client and my CDN (Cloudflare) and whatever's going on locally between the tunnel daemon and my local web server process.
For example you can choose to run these tunnels without HTTPS at all on your local webserver (bearing in mind that you have no inbound firewall ports open to the webserver box - no traffic leaves that box unencrypted), the daemon directly proxies your local-only HTTP port on the machine over an encrypted tunnel to Cloudflare and via whatever flavour of Cloudflare TLS you like to your end-users.
I've run some eCommerce sites before, we were PCI Tier 1, roughly 1% of web traffic: but nowhere _near_ the level of security Klarna should have; we had the CDN's activated only on subdomains... always.
Usually static.<site>.com or whatever..
This has the added benefit of not sending cookies to the CDN, because that can affect latency and is also a bit less secure because a static image/css/js does not need the cookie. (and bandwidth, before we were charged per byte (and that's egress now anyway in most cases, god I'm old.)).
If I had to venture a guess, they're probably scared of getting slammed with a DDoS so they "guard" everything behind the CDN, it's not about caching.
We got slammed with DDoS's too so we had to have systems in place to push BGP routes via verisign to "scrub" the traffic... we didn't even have that many "credits" and it cost millions...
That is simply not correct.
The entire reason why Fastly is so popular is because it lets you cache the API using cache-bust on write. Between the request collapsing, shielding, and a near immediate cache invalidation caching API allows one to accept enormous spikes of traffic that normally would bring down the origins.
If they separated app/cdn/web with different SSL certificates, something like this wouldn't be possible even when developers eff up.