Phase 1: Facade Layer¶
Status: Done
Risk: Low — Kong sits in front of the monolith; all traffic still goes to the monolith on miss.
Rollback cost: Low — remove Kong from the load balancer; traffic returns directly to the monolith.
Goal¶
Establish the Kong API gateway as a routing facade without changing any monolith behavior. This is the prerequisite for all subsequent extractions — you cannot route traffic to new services until the routing layer exists.
What Changes¶
| Before | After |
|---|---|
| Load balancer → Monolith (direct) | Load balancer → Kong → Monolith (all traffic) |
| No per-path routing | Kong routes all paths to monolith by default |
| No JWT validation at edge | Kong validates JWT tokens; monolith receives pre-authenticated requests |
| No distributed tracing at edge | Kong propagates traceparent headers; OTEL pipeline receives Kong spans |
Go / No-Go Criteria¶
Go condition: All monolith paths return the same response with Kong in the path as without (verified by traffic shadow/comparison test for 24 hours at 100% weight).
No-go signals: - Latency p99 increase > 5ms (Kong overhead budget) - Any 5xx introduced by Kong routing - JWT validation false positives (valid tokens rejected)
Rollback¶
- Update load balancer target group to point back to the monolith ALB directly.
- Kong stack remains deployed but receives no traffic — safe to decommission after 48-hour observation.