[Question] v0.7.0 Redis request count sync pattern — per-pod in-memory counting with periodic Redis sync vs. direct Redis operations — real-time accuracy concerns

We understand that v0.7.0 introduced syncing request counts (runningRequests) to Redis, but from what we can tell (please correct us if we're wrong), the pattern appears to be:

1. Each pod does ±1 counting locally in memory via atomic.AddInt32
2. Periodically, the in-memory count is batch-synced/flushed to Redis

Rather than doing direct INCR/DECR operations on Redis.

Our concerns:

If this is a periodic-sync approach:

1. Significant real-time lag: Within the sync interval (even 1-10 seconds), the values in Redis are always stale. In LLM inference scenarios where requests complete in sub-second to seconds, this means the routing algorithm is making decisions on outdated data.
2. Contradiction with least-request routing: The fundamental premise of least-request routing is that runningRequests reflects the current load on each Pod. A seconds-old snapshot undermines this premise — potentially even worse than purely local counting (which at least has zero network delay).
3. Atomicity regression: Moving from atomic.AddInt32 (nanosecond-scale, lock-free) to periodic sync (second-scale, network overhead) is a trade-off that adds global visibility but sacrifices timeliness.

Questions:
1. What was the design rationale behind this approach? Is it primarily for sharing request counts across multiple gateway instances?
2. Have you done comparative testing (pure local counting vs. periodic Redis sync) on routing quality metrics such as P50/P99 TTFT and load distribution fairness?
3. Have you considered direct INCR/DECR on Redis (with pipeline batching to reduce network overhead), or a hybrid approach where local atomic counts are used for real-time routing decisions while Redis serves asynchronously for monitoring/recovery?