LockWatch Substantive Improvements
------------------------------------


Atomic JWT Rotation via Redis Transactions
------------------------------------------

The rotate() method in jwt_rotation.py performs three Redis operations in sequence: it checks that
the refresh token hash exists, deletes that hash, and then issues a new pair. A concurrent rotate()
call with the same token can pass the existence check before the first call deletes the key,
resulting in two valid new token pairs. The fix is to wrap the exists check and delete in a Redis
MULTI/EXEC transaction (or use a Lua script, which executes atomically on the server). The PLAN.md
acknowledges this gap explicitly and labels it a Phase 2 improvement. Fixing it would also be a
strong interview talking point since most candidates do not identify this class of race condition.


Sliding-Window Memory Efficiency at High Cardinality
------------------------------------------------------

The current sorted set design stores one Redis member per request for every active key. For a
public API with hundreds of thousands of distinct IP addresses all within a 60-second window, Redis
memory usage grows proportionally to request volume times key count. A token bucket design using
a hash storing (last_refill_time, current_tokens) per key would use constant memory per key
regardless of request rate. The tradeoff is that token bucket does not give true sliding semantics
for burst burst analysis, but for simple rate limiting with a configurable burst allowance it is
far more memory-efficient. An alternative is to compress the sorted set into a fixed-size Count-Min
Sketch with probabilistic counting, though that introduces false positives.


Per-Route Rate Limit Policies
-------------------------------

LockWatch currently applies a single global policy to every request. Real APIs need differentiated
limits: stricter limits on authentication endpoints (5 req/min on /auth/login), looser limits on
static data endpoints (1000 req/min on /catalog). Implementing this as a route-to-policy mapping
passed at middleware initialization, or as a FastAPI dependency that injects a per-route RateLimiter,
would make LockWatch applicable to the full range of production use cases rather than only uniform-
policy APIs. The RateLimiter class is already designed as a standalone object, so the dependency
injection pattern would require minimal changes to the core.


Machine Learning Layer on Audit Log
-------------------------------------

The anomaly detector fires on raw burst counts, which catches volumetric attacks but misses slow
credential-stuffing attacks distributed across many IPs. The audit log already records all the
signals needed for behavioral analysis: endpoint patterns, user_id sequences, anomaly_detected
flags, and latency_ms. A scheduled job that trains a simple isolation forest or DBSCAN model on
recent audit log data and feeds back anomaly scores to a configurable threshold would turn the audit
log from a passive record into an active defense layer. This is the "V7 Data/Observability" resume
angle described in PLAN.md and would significantly differentiate LockWatch from commodity rate
limiters.


Prometheus Metrics Exporter
-----------------------------

LockWatch has no metrics surface. Adding an optional lockwatch[metrics] extra that exposes a
Prometheus Counter for rate-limit blocks per key, an anomaly event counter per IP, and a Histogram
for audit write latency would make the library production-observable without requiring users to add
their own instrumentation. The middleware dispatch method already measures latency_ms, so the
histogram data is already computed; it just needs to be emitted.


JWKS Endpoint and Asymmetric Key Rotation
-------------------------------------------

The RS256 design implies that the public key should be published for downstream services to use
without out-of-band configuration. Adding an optional router (FastAPI APIRouter or Flask Blueprint)
that serves /.well-known/jwks.json with the RSA public key in JWK format would complete the
standard OAuth 2.0 / OIDC token verification story. Key rotation (issuing tokens with a new RSA
key pair while still accepting tokens signed by the old key for a grace period) would require
tracking key IDs (kid claims) in the JWT header, storing multiple public keys in the JWKS response,
and retiring old keys after their longest-lived tokens expire. This is a non-trivial but
well-understood pattern that would make the JWT module resume-worthy at a senior level.


Distributed Rate Limiting via Redlock
---------------------------------------

The current design is correct for a single Redis instance but does not protect against two
application replicas both allowing a request when Redis is momentarily partitioned. Implementing
Redlock over a three-node Redis setup for the rate limit key acquisition would make the limiter
correct under failure scenarios that the current design does not handle. This is explicitly called
out in the PLAN.md interview narrative as the main known gap. Even a documented alternative that
explains why Redlock adds latency and recommends Redis Cluster with hash slots for the key as a
simpler production approach would demonstrate the level of awareness that makes this project
convincing on a resume.
