Dynamic API Gateway & Reverse Proxy

/metrics never reports how close a client is to being throttled

Right now the only rate-limit signal exposed via `/metrics` is a counter of rejections that already happened. There is no way for an on-call dashboard or alert to see a client approaching its limit before it actually gets throttled -- graphing "client X is down to 2 tokens, about to get cut off" is impossible today; the only visibility is after the 429s start, which is too late to react proactively.

DELETE /admin/routes/{id} can never delete a route that exists

Operators use `DELETE /admin/routes/{id}` to pull a route out of service -- decommissioning an old upstream, cutting off a route someone misconfigured, removing access during an incident. Right now that does not work: deleting a route that is actually in the table always 404s, so the only way to remove a route is a full `POST /admin/routes/reload` from a hand-edited `routes.yaml` (a much riskier, all-or-nothing operation) or restarting the process. During an incident where the fastest fix is "just take this one route out," that extra friction costs real time.

Admin API has no way to update just one field of a route

Today, changing just one route's rate limit during an incident (turning it down because a client is hammering an upstream, say) means reconstructing and re-sending the entire route body from whatever the operator currently has on hand -- easy to get subtly wrong (drop a field by accident, revert someone else's more recent change to a different field) under exactly the time pressure where a small, targeted change is what is needed.

Combined strip_prefix and add_prefix produce the wrong upstream path

Any route that uses both `strip_prefix` and `add_prefix` together (a common combination -- "drop our external `/api/v1` prefix and route into the upstream's own `/v2` namespace instead") sends every request to the wrong upstream path. Depending on the upstream, that is either a wave of 404s for a route that looks correctly configured, or -- worse -- silently hitting a different, unintended endpoint on the upstream if one happens to exist at the wrong path.

A malformed routes.yaml silently wipes out every route

`POST /admin/routes/reload` is the operational escape hatch for pushing route changes without a redeploy. If someone makes a typo in `routes.yaml` -- a bad indent, a field that fails a validator, a missing required key -- the reload endpoint does not fail loudly; it silently succeeds with an empty route table. Every route disappears, every proxied request starts 404ing, and the response the operator who ran the reload actually sees gives no indication anything went wrong. This turns a typo into a full outage that looks, from the caller's side, like a successful operation.

Maintenance mode toggles but never actually blocks traffic

A planned maintenance window (upstream migration, a scheduled Redis failover, a config change that needs a moment of "do not send anything through yet") currently has no clean way to pause traffic at the gateway without actually tearing down routes one by one or stopping the process. A single, fast, reversible kill switch is the kind of thing that is much better to have before the first time it is needed under pressure than to improvise in the moment.

Circuit breaker needs one more failure than configured to trip

The circuit breaker exists so a dead upstream does not tie up gateway capacity waiting out repeated timeouts. A route configured with `failure_threshold: 5` is supposed to trip after the 5th consecutive failure. Right now it takes a 6th -- meaning every route's breaker is quietly one failure more tolerant than whoever configured it intended. For a route tuned with a low threshold specifically to fail fast (`failure_threshold: 1` or `2`), that off-by-one is proportionally huge: a `threshold: 1` route effectively behaves like `threshold: 2`, doubling how many failed requests get sent into an already-failing upstream before the breaker does its job.

/metrics reports OPEN and HALF_OPEN breaker states swapped

`gateway_circuit_breaker_state` is the numeric metric an alerting rule or dashboard would graph to know when an upstream's breaker trips (its own doc comment says "0=closed, 1=open, 2=half_open"). Right now `open` and `half_open` are swapped in the lookup table that feeds this gauge -- so a dashboard built against the documented mapping shows an upstream as merely probing recovery (2, half-open) at the exact moment it is fully open and rejecting all traffic, and shows it as fully open (1) during the brief, mostly-harmless half-open probing window. Anyone paging off this metric with "alert if value == 1" would get paged for the wrong condition, or miss the real outage.

No way to cap how large a request body a route will accept

An upload endpoint with no size cap is a resource-exhaustion vector -- intentional (a hostile client deliberately sending a huge body to exhaust gateway or upstream memory/disk) or accidental (a buggy client retry-looping a multi-GB file). This gateway already proved, at some effort, that it can stream a 700MB response through without buffering it; a size limit implemented by buffering the request body would throw away exactly that property on the other side of the same connection.

X-Request-Id is the same hardcoded value on every response

A request ID is only useful for tracing/correlation if it is actually unique per request -- "every request gets the label stub-request-id" is equivalent to not having request IDs at all for debugging purposes (searching logs for it returns everything, which is the same as searching for nothing). And silently overwriting a client-supplied ID breaks any correlation the client was already trying to do across its own systems and this gateway.

A requests_per_second: 0 route crashes instead of blocking traffic

`requests_per_second: 0` is a reasonable, sensible-looking way to configure "block all traffic on this route through the rate limiter" (e.g. temporarily killing a specific client's access without deleting their route or auth credential entirely). Instead of cleanly rejecting every request with 429, the route errors out on every single request -- the rate-limit check itself throws, which the gateway has no specific handling for, so it surfaces as an unhandled exception. What was meant to fully block a client instead breaks the route for everyone hitting it, in a way that is much harder to diagnose than a plain 429 would be.

A route with multiple upstreams never uses any but the first

This is the difference between "one upstream, with additional_upstream_base_urls unused" and actually being able to run more than one instance of an upstream behind a single route -- which is the entire point of adding the field in the first place. A route stuck always hitting its first configured upstream cannot be horizontally scaled by adding more upstream instances to its config; every added upstream is dead weight that never receives traffic.

A burst of concurrent requests during half-open all get admitted at once

Half-open exists specifically to send a trickle of probe traffic (by default, one request) at a just-recovered upstream, instead of slamming it with the full concurrent load the gateway was holding back -- an upstream that is recovering from an outage is often still fragile, and a sudden thundering herd of every previously-blocked request landing on it at once can knock it right back down, defeating the entire purpose of having a gradual recovery probe. Under concurrent traffic, that is exactly what happens today: as soon as the recovery window elapses, a burst of concurrent requests all get admitted as "probes" at once, regardless of `half_open_max_probes`.