HTTP/3-first ingress,
backends untouched
Spooky is a focused reverse proxy runtime: clients connect over HTTP/3, backends serve HTTP/1.1 or HTTP/2 — no changes required. Deterministic routing, per-upstream resilience controls, and OpenTelemetry-compatible observability — currently in beta, with a documented path to GA.
Current State
HTTP/3 ingress, HTTP/1.1 and HTTP/2 backend support, 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. Backends can be HTTP/1.1 or HTTP/2 — Spooky dispatches by scheme automatically, with both transports pooled independently. Active health checks, Prometheus metrics, OTLP tracing, and bounded overload behavior are included and enabled via config. Backend DNS refreshes at runtime without a restart.
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.
- Deployments that need explicit forwarding control — X-Forwarded-For mode, Host header policy, and per-upstream TLS are all config-level knobs.
The request path
from client to backend
Spooky terminates QUIC connections at the edge and forwards to HTTP/1.1 or HTTP/2 backends based on the backend scheme. 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/1.1 or HTTP/2 based on the backend scheme.
- Host, path, and method matching with deterministic tie-breaking
- Per-upstream load balancing strategy and health-aware backend selection
- Scheme-aware dispatch — https:// backends use HTTP/2, http:// backends use HTTP/1.1
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 to the backend protocol. Backends can be HTTP/2 or HTTP/1.1 — both transports are pooled independently within the same upstream. The protocol translation happens entirely within the edge runtime.
- HTTP/3 to HTTP/2 or HTTP/1.1 translation, scheme-determined per backend
- Independent connection pools for HTTP/2 and HTTP/1.1 backends
- Backends require no protocol changes — http:// and https:// are both supported
Backends receive routed traffic from healthy pools. HTTP/1.1 and HTTP/2 backends can be mixed within the same upstream pool. Retries, circuit behavior, and per-backend inflight caps are all policy-driven and scoped per upstream — not applied globally.
- Per-upstream health checks routed through the correct transport per backend scheme
- Backend DNS refreshed at runtime on a configurable interval — no restart when targets change
- 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 upgrade. Backends serve HTTP/1.1 or HTTP/2 — scheme-aware dispatch picks the right transport automatically.
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 operations: live reload, SNI routing, per-upstream policy
Listener certs reload live without restart. SNI-based cert selection for multi-domain listeners. Each upstream pool can specify its own CA, cert, and verification settings independently. Downstream mTLS enforced via rustls — no OpenSSL dependency.
Prometheus metrics, OTLP tracing, and structured logs
Prometheus endpoint with request, backend health, and inflight metrics. OTLP tracing configurable via standard environment variables. Structured JSON logs with per-request detail. Cert expiry and health transition telemetry included out of the box.
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.