Why netweft's cache and rate limiter fail open
netweft's cache and rate limiter fail open: a cache that cannot answer is a miss, and a limiter that cannot count lets the request through, so the product keeps working, more slowly and more permissively. Choosing that up front is what stops a performance dependency becoming an availability one.
The cache and the rate limiter in netweft do two jobs: the cache keeps provider responses so a repeated lookup is not bought twice, and the limiter counts how fast a workspace is calling. Neither of them is the product. Both of them are optimisations of it.
So the question worth answering early is not what happens when they are fast enough but what happens when they are not there at all — and the answer has to be decided rather than discovered.
This post first described Redis, which did both jobs when it was written. On 2026-10-10 netweft moved onto Cloudflare: the cache is now Workers KV and the limits are Workers Rate Limiting. The decision below did not change, which is the point of having made it about the behaviour rather than the vendor.
The decision
Every cache misses. A cache that cannot be read is a cache miss, and a cache miss is a slower correct answer. The provider gets called, the credits get spent, the response gets stored where it can be. Nothing is wrong; it is more expensive and slower, which is exactly what a missing cache should cost.
Every rate limit allows. This is the one people flinch at. The alternative is that a limiter outage refuses every request in the product, which converts a performance dependency into an availability dependency — a counter that cannot count taking down the whole API is a spectacularly bad trade.
The exposure is bounded by something more fundamental anyway: nothing in netweft can spend money it does not have. Credits are reserved before a call goes out, and a workspace with no credits is refused whether or not a rate limiter is available to have an opinion. The rate limit protects against rapid spending of credits that exist. It is not the thing standing between a workspace and an unlimited bill.
Why writing it down matters more than the choice
Most systems have a degraded mode. Very few have a stated one, which is why outages are surprising — the behaviour under partial failure was never chosen, so it is whatever falls out of the code paths nobody read.
Stating it has a second effect. Once “no cache” is a supported configuration rather than a catastrophe, it becomes one you can test in: the API’s own suite runs with no cache and a limiter that allows everything, the same way the mock data provider makes a working netweft without a vendor account.
A dependency you can switch off is a dependency you understand.