One gateway topology instead of four teams' worth of entry points
Kong
Kubernetes
PostgreSQL
DockerNGINXThe business units migrated onto a single gateway topology in sequence without a coordinated cutover, and gateway configuration became reviewable in pull requests rather than applied by hand.
Overview
Kong is usually adopted one team at a time, and the result is several independently configured gateways with incompatible auth, inconsistent logging, and no shared view of what is exposed. Consolidating them is an architecture problem before it is a Kong problem.
Challenge
Four business units had each stood up their own gateway. Authentication varied between API keys, JWT, and mutual TLS with no common consumer model. Configuration was applied by hand in some environments and by declarative config in others, so promotion between environments was not reproducible. Nobody could produce a definitive list of externally reachable routes.
Environment
Kong across on-premises data centers and a managed Kubernetes cluster, fronting a mix of legacy SOAP services and newer REST APIs.
Approach
AceMQ designed a hybrid control plane and data plane topology with a single declarative source of truth for gateway configuration, held in version control and promoted through environments. Auth was standardized on a common consumer and credential model, with per-service exceptions documented rather than improvised.
Solution
- 1Designed a hybrid control plane / data plane topology with data planes close to their workloads
- 2Standardized configuration as declarative files in version control with an environment promotion pipeline
- 3Defined a single consumer and credential model, with documented exceptions for legacy services
- 4Established a shared plugin baseline for logging, tracing, request size limits, and rate limiting
- 5Planned staged migration of each business unit's routes with parallel-run and rollback per service
- 6Produced an authoritative inventory of externally reachable routes and their auth posture
Outcome
The business units migrated onto a single gateway topology in sequence without a coordinated cutover, and gateway configuration became reviewable in pull requests rather than applied by hand.
Technologies
KongKubernetesPostgreSQLDockerNGINXRelated Use Cases
Kong Plugin and Latency Assessment
Measuring where request latency is actually spent inside the Kong plugin chain, and which plugins are worth their cost.
Kong Rate Limiting Consistency Support
Fixing rate limits that allowed several times the configured quota because the plugin was using the local counter policy across a multi-node gateway.
Need Kong Architecture Guidance?
AceMQ's senior Kong engineers have handled this exact type of engagement before. Whether you need architectural guidance, hands-on remediation, or an ongoing managed partnership, we're ready to help.