Fair, a single global guard shouldn't carry one blanket failure policy, defaulting open, with fail-closed reserved for the specific routes where sensitive operations are carried out. Login endpoint will also fail open.
Good callout on webhook retries too, I hadn't separated that from general traffic. A flat limit treating a legitimate retry storm the same as abuse, exactly when you'd want the opposite, is a real gap. Worth handling on its own rather than folding it into the same limit. Fixing both.
Thank you for your input.
The thing I'd flag from running Redis-backed throttling in production: what happens when Redis itself blips matters as much as the ttl/limit numbers. A global APP_GUARD throttle that fails closed on a Redis hiccup turns a two-second cache blip into "nobody can log in," which is a worse outage than the abuse it's meant to stop. Fail-open at the global layer and reserve fail-closed for the specific routes where you'd rather reject than risk letting something through unmetered. The other one worth rehearsing on Titan specifically: legitimate retries from an upstream payment webhook don't back off politely on a 429 the way a browser does, so the exact moment you're mid-incident and getting hammered by real retries is also the moment a flat global limit is most likely to start eating legitimate traffic.