Roadmap

Previous

Current Status

Beta. Core features are functional and tested. Spooky can terminate HTTP/3 connections, forward to HTTP/2 backends, and perform load balancing with health checks. It is pre-GA and should be deployed with production guardrails (see Release Maturity and Technical Debt below).

Completed

  • HTTP/3 termination via quiche
  • HTTP/2 backend connectivity
  • Path and host-based routing
  • Multiple load balancing algorithms (random, round-robin, consistent hash, least-connections, latency-aware, sticky-cid)
  • Active health checking with automatic backend management
  • Per-upstream configuration and routing
  • Connection ID management and QUIC packet routing
  • TLS 1.3 with certificate chain loading
  • Upstream TLS peer verification enabled by default via upstream_tls.verify_certificates
  • Downstream mTLS (client certificate authentication) via listen.tls.client_auth.enabled, listen.tls.client_auth.require_client_cert, and listen.tls.client_auth.ca_file
  • Structured logging with multiple levels
  • Configuration validation at startup
  • Graceful shutdown with connection draining

Phase 1: Operational Hardening

Goal: Expand operational and scalability capabilities for production deployments.

Performance

  • Async data plane: Move backend forwarding off the main poll thread
  • Streaming bodies: Implement incremental request/response streaming instead of full buffering
  • Multi-threading: Support multi-threaded QUIC packet processing
  • Connection pooling optimizations: Reduce allocation overhead in HTTP/2 pool

Observability

  • Metrics export: Prometheus endpoint live — per-route counters, latency percentiles, active-connection and queue-size gauges, full drop counter coverage across all ingress paths
  • Resilience metrics: Per-feature counters for retries (attempt + denial by reason), hedges (triggered/won/wasted/latency), circuit breaker rejections, and brownout state gauge
  • Distributed tracing: OpenTelemetry integration
  • Request logging: Per-request structured logs with correlation IDs
  • Connection metrics: Track QUIC RTT, packet loss, stream count

Operational

  • Configuration hot reload: Reload config on SIGHUP without dropping connections
  • Health check improvements: Separate client pool for probes to avoid contention
  • TLS certificate reload: Automatic reload on certificate rotation
  • Admin API: HTTP endpoint for runtime statistics and control

Reliability

  • Circuit breaker: Per-backend circuit breakers to prevent cascading failures
  • Retry logic: Configurable request retry with exponential backoff
  • Request timeouts: Per-route timeout configuration
  • Rate limiting: Per-IP and per-route rate limits

Phase 2: Advanced Features

Goal: Add advanced traffic management and operational capabilities.

Traffic Management

  • Weighted routing: Route percentage of traffic to different upstreams
  • Header-based routing: Route by arbitrary request headers
  • Request rewriting: URL rewriting and header manipulation
  • Compression: Automatic response compression

Load Balancing

  • Weighted least connection: Combine weights with connection count
  • Cached consistent hash: Cache hash ring to avoid rebuilds

Security

  • mTLS operational tooling: Certificate rotation/revocation workflows and deployment guidance
  • Request validation: Size limits, header validation
  • IP allowlist/blocklist: Simple access control

Deployment

  • Dynamic backend discovery: Service discovery integration (DNS SRV, Consul, etcd)
  • Backend metadata: Tags and labels for flexible routing
  • A/B testing support: Route subset of traffic to experimental backends
  • Canary deployments: Gradually shift traffic to new backend versions

Phase 3: Enterprise Features

Goal: Support large-scale deployments with advanced requirements.

Multi-Tenancy

  • Namespace isolation: Separate routing tables per tenant
  • Resource limits: Per-tenant connection and request limits
  • Tenant routing: Route by tenant ID or subdomain

Advanced Observability

  • APM integration: Datadog, New Relic, etc.
  • Custom metrics: User-defined metric collection
  • Traffic replay: Record and replay production traffic
  • Query logs: SQL-like queries over request logs

Protocol Features

  • gRPC support: Native gRPC proxying
  • WebSocket support: WebSocket over HTTP/3

High Availability

  • Connection migration: Support QUIC connection migration
  • State replication: Share connection state across instances
  • Zero-downtime updates: Binary updates without connection loss
  • Multi-region support: Geographic routing and failover

Phase 4: Protocol Extensions

Goal: Support emerging protocols and optimizations.

HTTP/3 Features

  • 0-RTT support: Enable 0-RTT with proper anti-replay measures
  • QUIC multipath: Support multiple network paths
  • Datagram support: QUIC DATAGRAM frames for low-latency data
  • Priority trees: HTTP/3 priority and scheduling

Additional Protocols

  • HTTP/1.1 support: Serve HTTP/1.1 clients
  • TCP proxy mode: Layer 4 TCP proxying
  • UDP proxy: Forward UDP traffic
  • MQTT support: IoT protocol support

Optimizations

  • Zero-copy: Eliminate unnecessary data copies
  • Kernel bypass: AF_XDP or DPDK integration
  • Hardware offload: TLS offload to NICs
  • eBPF: Use eBPF for packet filtering and routing

Implementation Priorities

High Priority (Next 3 months)

  1. Async data plane - unblock main thread
  2. Configuration hot reload - reduce operational friction
  3. Streaming bodies - reduce memory usage
  4. mTLS operational tooling - certificate lifecycle automation

Medium Priority (3-6 months)

  1. Circuit breakers - improve reliability
  2. Distributed tracing - debugging complex issues
  3. Rate limiting - protect backends
  4. Health check improvements - reduce contention
  5. Admin API - operational visibility

Low Priority (6+ months)

  1. Dynamic backend discovery - integration complexity
  2. Advanced load balancing - diminishing returns
  3. Advanced protocol features - adds complexity
  4. Protocol extensions - limited immediate value
  5. Multi-tenancy - niche use case

Technical Debt

Current Known Issues

  1. Blocking backend calls: Main thread blocks during HTTP/2 requests
  2. Full body buffering: High memory usage for large requests/responses
  3. Configuration hot reload missing: Runtime config updates still require restart
  4. Dual-ingress operational complexity: Runtime serves HTTP/3 (native) plus HTTP/1.1/2 TLS bootstrap, so operators must secure and observe both paths consistently
  5. Method-based route matching constraints: keep route precedence and method tie-break semantics covered by integration tests as routing rules evolve
  6. Control/metrics endpoint hardening is operator-dependent: endpoints should remain network-isolated unless explicitly protected

Refactoring Needs

  1. Error handling: Unify error types across crates
  2. Configuration: Type-safe config builders
  3. Testing: Expand integration test coverage
  4. Documentation: API documentation and examples
  5. Logging: Reduce debug log verbosity in hot path

Non-Goals

Features explicitly not planned:

  • Full service mesh: Focus remains on edge proxying
  • Content caching: Use CDN or dedicated cache
  • WAF capabilities: Use dedicated security tools
  • Database proxying: Use specialized database proxies
  • Custom protocols: Stick to HTTP family
  • In-process plugin/extension ABI: No WASM/eBPF/Lua middleware model until a safe isolation and lifecycle model is defined

Contributing

Contributions are welcome. See contributing guide for development setup and guidelines.

Priority areas for contributions:

  1. Streaming request/response bodies
  2. Configuration hot reload
  3. Distributed tracing (OpenTelemetry)
  4. Integration tests
  5. Documentation and examples
References