API Sentinel

Architecture

A request playground submits predefined calls into a local policy engine. The engine evaluates authentication, authorization, schema requirements, idempotency keys, a token-bucket rate limit, and a circuit breaker, then records an inspectable history. No network hop is made.

Request fixture → identity check → schema validation → idempotency lookup → rate-limit token → circuit state → response contract → history and counters.

Decisions

• — Keep HTTP status codes as the public contract and pair each one with a policy reason.
• — Derive operational totals from the same request history the inspector shows.
• — Treat idempotency as a first-class key store rather than a silent retry.

Trade-offs

• — A token bucket is explainable and it can still starve a bursty but legitimate client.
• — Failing closed on an open circuit protects upstreams and it hides healthy traffic until the breaker resets.
• — Strict required-field checks catch bad payloads and they reject clients that send extra optional shape.

Failure modes

• — A missing Authorization header is 401 even when the body is valid.
• — A previously seen idempotency key returns 409 instead of creating a second order.
• — An open circuit returns 503 regardless of remaining rate-limit tokens.

Evaluation

The demo is evaluated by whether changing a policy control changes subsequent request outcomes and the derived counters stay consistent with history.

Production extensions

Proposed — not implemented in this portfolio.

• — Replace the in-memory bucket with Redis sliding windows.
• — Add signed JWTs and real RBAC instead of simulated identity outcomes.
• — Emit structured access logs and traces per hop.