An internal service needs to fetch user data from a billing service—and every millisecond matters. Routing this internal traffic through a public-facing edge gateway forces your request to leave the private network, pass through external firewalls, and incur unnecessary serialization overhead. This path can easily add 30 milliseconds of latency to a single dependency call.
Internal service-to-service communication requires a different architectural approach than edge routing. At the edge, you need public developer portals, complex rate limiting for external clients, and heavy OAuth2 validation. Internally, you need low latency, native service discovery, and minimal operational friction.
Choosing the right API gateway for internal microservices depends on how much operational overhead your team can handle versus your need for raw performance.
The internal microservices routing challenge: Self-hosted vs. managed
Platform architects face a fundamental choice when designing internal routing—deploy and manage a self-hosted gateway close to the services, or offload the infrastructure to a managed cloud service.
Self-hosted gateways run inside your private network—often as sidecars or ingress controllers in a Kubernetes cluster. This deployment model keeps traffic local, which minimizes latency. It also gives you complete control over routing rules, header manipulation, and service discovery integrations with tools like Consul or Etcd. However, your team must manage the underlying virtual machines, scaling policies, and upgrades.
Managed cloud gateways run as external services. They require almost zero maintenance and scale automatically to handle traffic spikes. The trade-off is latency and cost. Every internal request must travel to the cloud provider's gateway endpoint and back into your virtual private cloud (VPC). This extra network hop introduces latency that can degrade the performance of chained microservice calls.
Kong: High performance with a plugin-heavy ecosystem
Kong is an open-source gateway built on top of the Nginx web server and the OpenResty web platform. Because it inherits Nginx's event-driven architecture, Kong excels at high-throughput, low-latency routing.
[Internal Request] ---> [Kong Gateway (Nginx/OpenResty)] ---> [Target Microservice]
|
[Lua Plugins] (Auth, Rate Limiting, Logging)
Kong uses Lua for extensibility. If you need to modify headers, inject authentication tokens, or log requests to Prometheus, you apply a plugin. The open-source version, Kong Gateway OSS, includes a wide selection of community plugins. For advanced enterprise features like role-based access control (RBAC) and multi-zone deployment, teams must transition to Kong Enterprise.
Managing Kong requires managing its configuration state. You can run Kong in a traditional database mode, which requires a PostgreSQL database to store routing configurations. Alternatively, you can run Kong in DB-less mode. In DB-less mode, you write configurations in a declarative YAML file and apply them directly to the gateway's memory. This approach works well in GitOps workflows and Kubernetes environments—but it means you cannot use some plugins that require dynamic database storage.
Tyk: Feature-complete and Go-native out of the box
Tyk is an open-source API gateway written entirely in Go. Unlike Kong, which relies on a modular plugin architecture for core features, Tyk includes rate limiting, analytics, and service virtualization directly in its core engine.
Because Tyk is written in Go, it appeals to teams with existing Go expertise. Developers can write custom plugins in Go, Python, JavaScript, or Lua using Tyk's gRPC-based plugin coprocessor.
Tyk requires Redis to operate. It uses Redis for session storage, rate limiting counters, and caching. While this database dependency adds an operational component to manage, Redis allows Tyk to process high volumes of traffic with predictable, low latency. Tyk's open-source version is highly functional, offering the same gateway engine as the paid enterprise edition—though the enterprise tier adds a management control plane and dashboard.
Cloud-native options: AWS API Gateway and platform managed services
If your infrastructure runs entirely in a public cloud, managed options like AWS API Gateway, Azure API Management, or Google Cloud Apigee are highly accessible.
AWS API Gateway integrates directly with other AWS services. You can route an incoming API call directly to an AWS Lambda function, an SQS queue, or an internal Application Load Balancer (ALB) without writing custom integration code. Security is handled through AWS Identity and Access Management (IAM) policies, which simplifies access control.
However, cloud-managed gateways introduce performance trade-offs:
- Cold starts: If you integrate with serverless backends, the initial request can take several seconds to resolve.
- Network hops: Traffic must often exit your private subnet to reach the gateway's public endpoint before routing back into your private network.
- Vendor lock-in: Configurations are tied to the cloud provider's proprietary APIs and deployment tools.
For high-throughput internal microservices, these factors can make cloud-native options less suitable than self-hosted alternatives.
Decision framework: Choosing by team size and operational budget
To choose the right gateway, evaluate your team's capacity to manage infrastructure against your performance requirements.
Small startup teams (1 to 10 developers)
If you have a small team, prioritize low operational overhead. Use your cloud provider's managed gateway (such as AWS API Gateway) to get your services running quickly. At this scale, the ease of setup and zero-maintenance model outweighs the minor latency penalties.
Mid-size platform teams (10 to 50 developers)
As your service mesh grows, cloud gateway costs scale linearly with request volume. At this stage, self-hosting becomes financially and operationally viable.
Let us look at a realistic cost comparison:
- Managed Scenario (Example): A mid-sized application processes 100,000,000 internal requests per day. At an illustrative cloud gateway price of $3.50 per million requests, the routing cost alone is $350 per day—or roughly $10,500 per month.
- Self-Hosted Scenario (Example): The same team deploys Kong or Tyk on their existing Kubernetes cluster. They run three small compute instances for high availability, costing a total of $150 per month in compute resources.
The self-hosted option saves significant budget—but it requires the platform team to spend a few hours each month managing updates, monitoring Redis or PostgreSQL, and configuring deployment pipelines.
Enterprise platform teams (50+ developers)
For large organizations with strict compliance and sub-millisecond latency requirements, self-hosted gateways are almost always necessary. These teams typically deploy Kong or Tyk in a hybrid or multi-region configuration to keep traffic entirely within local data centers or VPCs.
| Selection Criteria | Kong | Tyk | AWS API Gateway |
|---|---|---|---|
| Primary Language | Lua / C | Go | Proprietary |
| Database Dependency | PostgreSQL or DB-less | Redis | None (Managed) |
| Extensibility | Lua Plugins | Go, Python, gRPC | AWS Integrations |
| Latency Profile | Sub-millisecond | Low (microsecond range) | Moderate (network hops) |
| Best Fit | High-performance Nginx environments | Go-centric teams wanting out-of-the-box features | Serverless and pure AWS architectures |
Evaluate your API infrastructure options on StackMatch
Selecting the right API gateway is a critical architectural decision that impacts your system's latency, cost, and operational complexity. You can explore more options and compare these tools in depth on StackMatch. StackMatch provides curated tool listings, side-by-side comparison pages, and editorial scoring based on ease of use, pricing transparency, and integrations to help platform engineers find the right fit for their specific tech stack.
FAQs
Is Kong faster than AWS API Gateway for internal routing?
Yes, Kong generally offers significantly lower latency than AWS API Gateway. Because Kong runs on Nginx and can be deployed within your private VPC close to your microservices, it avoids the network hops and cold starts associated with AWS's fully managed service.
Can I run Tyk without a database?
Tyk requires Redis for caching, rate limiting, and session storage. While you cannot run it completely stateless without Redis, this architecture allows Tyk to handle high-throughput traffic with minimal latency compared to gateways that rely on relational databases.
When should a team transition from a cloud-native gateway to a self-hosted gateway?
Teams typically transition when cloud-native gateway bills scale linearly with API call volume, or when the added latency of WAN routing impacts internal microservice performance. If your internal services require sub-10ms response times, self-hosting Kong or Tyk on Kubernetes is usually necessary.
How do Kong and Tyk handle gRPC and GraphQL?
Both gateways support gRPC and GraphQL routing, but they handle them differently. Kong uses plugins for gRPC transcoding and GraphQL schema validation—while Tyk offers native GraphQL engine capabilities to merge multiple schemas into a single graph out of the box.