HTTP/3-first ingress,
backends untouched
Spooky is a focused reverse proxy runtime: clients connect over HTTP/3, backends stay on HTTP/2 as-is. Deterministic routing, per-upstream resilience controls, and Prometheus-native observability — currently in beta, with a documented path to GA.
Current State
HTTP/3 ingress, host/path routing, six load-balancing strategies, and per-upstream resilience — in beta and available now.
QUIC-based HTTP/3 ingress runs alongside bootstrap HTTP/1.1 and HTTP/2 on a parallel TLS path. Active health checks, Prometheus metrics, and bounded overload behavior ship in the core runtime.
Review technical overview →Best Fit Right Now
Platform and SRE teams where latency, explicit policy, and deterministic behavior matter most.
- API ingress for multi-service backends with explicit per-route policy.
- Front-door proxy in front of service mesh or application clusters.
- Incremental adoption starting from a single route or service group, with rollback gates at every step.
The request path
from client to backend
Spooky terminates QUIC connections at the edge and forwards to HTTP/2 backends unchanged. Between those two points, the runtime handles protocol translation, route resolution, health-aware backend selection, and layered admission control.
Modern clients connect over HTTP/3 on QUIC. For clients that haven't upgraded, Spooky exposes a parallel TLS bootstrap path for HTTP/1.1 and HTTP/2, with Alt-Svc signaling to advertise the HTTP/3 endpoint.
- Native HTTP/3 ingress on UDP with TLS 1.3
- Bootstrap HTTP/1.1 and HTTP/2 ingress on TCP/TLS
- Alt-Svc advertisement for HTTP/3 upgrade discovery
The runtime terminates QUIC, resolves the matching route, runs admission and resilience checks, selects a healthy backend, and forwards the request over HTTP/2.
- Host, path, and method matching with deterministic tie-breaking
- Per-upstream load balancing strategy and health-aware backend selection
- Layered admission control with bounded request and response caps
Active health checks run continuously against backends. Prometheus metrics and control API endpoints expose runtime state, health transitions, and inflight counts.
- Active health checks with configurable thresholds and cooldown
- Prometheus metrics endpoint at /metrics when enabled
- Control API readiness and runtime introspection endpoints
Spooky translates HTTP/3 requests into HTTP/2 for backend services. Backends speak HTTP/2 and need no changes — the protocol translation happens entirely within the edge runtime.
- HTTP/3 to HTTP/2 translation with header and body forwarding
- Connection pooling with bounded in-flight forwarding per backend
- Backends require no protocol changes or redeployment
Backends receive routed traffic from healthy pools. Retries, circuit behavior, and per-backend inflight caps are all policy-driven and scoped per upstream — not applied globally.
- Per-upstream health checks with failure classification
- Retry budgets and circuit breaker behavior are policy-driven
- Per-backend inflight cap isolates slow backends from the rest of the pool
The runtime built for
precise edge control
HTTP/3 and QUIC as the primary ingress path
Primary ingress runs QUIC + TLS 1.3 natively. HTTP/3 is the first-class path. Bootstrap HTTP/1.1 and HTTP/2 run in parallel with Alt-Svc signaling for phased upgrade — no changes needed on the backend side.
Trie-based routing with longest-match guarantees
Host, path prefix, and method matching resolve through a trie with deterministic tie-breaking. The same request always hits the same rule — no ambiguity during rollout or incident response.
Traffic distribution tuned per upstream pool
Stateless services use round-robin or least-connections. Latency-sensitive routes favor faster backends with EWMA weighting. Session-bound services use consistent hash or QUIC CID-based affinity. Each upstream pool decides independently.
Per-upstream circuit isolation and brownout mode
Circuit breaker, retry budgets, request hedging, and admission caps scoped per upstream. One failing backend triggers isolation — not a cascading outage. Brownout mode sheds load before saturation.
TLS 1.3 and mTLS via rustls — zero OpenSSL
Full TLS 1.3 termination and downstream mTLS enforcement via rustls. No OpenSSL dependency. Upstream TLS verification is on by default — cleartext upstreams require explicit opt-in.
Soak-tested and explicit under overload
Sustained load runs, failure injection, and protocol parity checks gate every release. Under overload, Spooky sheds load with deterministic 503 + Retry-After responses — not dropped connections or silent timeouts.
Six layers so one spike
doesn't take down everything
Most proxies give you a single connection limit — watch it trip and everyone gets 503s. Spooky has six admission layers, each scoped independently. A spike on one route cannot consume what another depends on.
The layers run from outermost to innermost. Brownout can shed whole routes under extreme pressure. Adaptive admission adjusts dynamically to real latency. Queue caps, global limits, upstream gates, and per-backend caps narrow from there — each one keeping a problem local.
Review the GA gate criteria →When overall pressure gets critical, non-core routes are shed entirely so traffic to payments, auth, and health keeps flowing. A hysteresis gap between activation and recovery prevents the system from toggling under sustained load.
A dynamic gate that reads real-time latency and tightens how many requests are accepted as the system slows. No fixed cap — it responds to what the system is actually doing.
Each route has its own queue. A spike on one endpoint cannot consume the shared queue and starve every other route. High-priority routes can hold more; low-priority routes hold less.
A system-wide hard ceiling every request must pass before forwarding. Nothing bypasses it — it is the floor beneath all other controls.
Each upstream pool has its own permit gate. A thundering herd on one upstream cannot drain the capacity every other service depends on.
The finest-grained gate, at the connection pool level. One slow backend gets isolated — the rest of the pool keeps accepting traffic normally.