# Roadmap: Fengling Gateway **Created:** 2026-03-02 **Core Value:** Reliable, scalable API gateway that distributes traffic to backend microservices with zero-downtime configuration updates. --- ## Phase 1: Console-Driven Configuration & Multi-Instance Support **Goal:** Implement console-driven configuration management and multi-instance support. **Requirements:** - CFG-01: Gateway listens to config change events from fengling-console - CFG-02: Gateway reloads configuration without restart when notified - CFG-03: Multi-instance gateway receives config updates via broadcast - INST-01: Multiple gateway instances can run simultaneously - INST-02: Configuration changes propagate to all instances - INST-03: Redis-based pub/sub for cross-instance communication **Success Criteria:** 1. Gateway can subscribe to config change events from console 2. Configuration reload works without gateway restart 3. Multiple gateway instances stay synchronized 4. Broadcast events reach all instances within 5 seconds --- ## Phase 2: K8s Health Delegation **Goal:** Remove K8s health monitoring from gateway, delegate to console. **Requirements:** - K8S-01: Remove K8s health monitoring from gateway - K8S-02: Gateway delegates service health checks to console **Success Criteria:** 1. KubernetesPendingSyncService is deprecated/removed from gateway 2. Health check logic moved to console project 3. Gateway only performs request routing, not health monitoring --- ## Phase 3: Security Hardening **Goal:** Fix critical security vulnerabilities. **Requirements:** - SEC-01: Remove hardcoded credentials from source code - SEC-02: Implement proper JWT token validation - SEC-03: Add authentication to gateway management API endpoints **Success Criteria:** 1. No hardcoded passwords/secrets in source code 2. JWT tokens are validated (signature, expiration, issuer, audience) 3. All /api/gateway/* endpoints require authentication --- ## Phase 4: Performance Optimization **Goal:** Optimize gateway performance under high load. **Requirements:** - PERF-01: Optimize load balancing lock contention - PERF-02: Implement incremental route cache updates **Success Criteria:** 1. Load balancing does not require per-request Redis lock 2. Route cache updates are incremental, not full reload 3. Gateway handles 10x more requests per second --- ## Phase 5: Observability & Testing **Goal:** Add observability and test coverage. **Requirements:** - OBS-01: Distributed tracing integration - OBS-02: Custom metrics for gateway performance - TEST-01: Unit tests for RouteCache - TEST-02: Unit tests for JwtTransformMiddleware - TEST-03: Unit tests for load balancing policy **Success Criteria:** 1. Distributed traces include gateway spans 2. Key metrics are exported (request count, latency, error rate) 3. Core components have >80% test coverage --- ## Roadmap Summary | Phase | Name | Requirements | Status | |-------|------|--------------|--------| | 1 | Console-Driven Config & Multi-Instance | 6 | Not planned | | 2 | K8s Health Delegation | 2 | Not planned | | 3 | Security Hardening | 3 | Not planned | | 4 | Performance Optimization | 2 | Not planned | | 5 | Observability & Testing | 5 | Not planned | **Total:** 5 phases | 18 requirements | All covered ✓ --- *Last updated: 2026-03-02 after roadmap creation*