If you’ve spent any time scaling a backend platform, the question shows up early and never really goes away: which API gateway? And then, almost on cue, the harder one — should we just build our own?
After a year of vendor evaluations across Kong, MuleSoft, Apigee, and Gravitee for enterprise rollouts, the honest answer is the unsatisfying one: there is no universally “best” gateway. Each platform is optimised for a different philosophy, and picking well is mostly about matching that philosophy to the shape of your traffic and your team.
1. The gateway is not just a reverse proxy
A lot of teams still think of an API gateway as nginx with a UI. That mental model leaves real value on the table.
A modern gateway is the control plane for everything that happens at the edge of your platform:
- Authentication — OAuth, JWT, mTLS, API keys
- Rate limiting, quotas, and burst shaping
- Traffic management — canary releases, blue/green cuts, weighted routing
- Request and response transformation
- Observability — structured logs, RED metrics, distributed traces
- Monetization — usage metering and billing for API products
Treat it as a load balancer and you’ll bolt all of this onto your services one by one until the platform team owns six libraries that should have been one config block.
The framing that helps — your gateway is the policy layer for traffic and business logic at the network edge. Pick it the way you’d pick a database, not the way you’d pick a CDN.
2. The four leaders, and what each is actually optimised for
Kong — performance first
Built on nginx with Lua plugins. In benchmarks I’ve run on a modest 8-core node, Kong sustains north of 100k requests/sec with sub-millisecond overhead. The plugin model is genuinely extensible — if you’re comfortable in Lua you can ship policy at the gateway in a day.
Best for: high-throughput platforms, teams that want a small, fast core they can extend themselves.
The catch: the open-source tier is generous on routing but thin on the things enterprises actually pay for — RBAC, dev portal, advanced analytics, OIDC. Lua is also a real ecosystem tax; if no one on your team has written it, plan for the learning curve.
MuleSoft — enterprise integration platform
MuleSoft is less an API gateway than a full iPaaS. The gateway is one capability inside a platform that includes 1,500+ pre-built connectors, a visual flow designer, and tight Salesforce integration.
Best for: large enterprises with serious system-integration needs — legacy ERPs, SAP, Salesforce, mainframes — where the gateway is the smallest part of the problem.
The catch: pricing starts where most teams’ API budgets end, and the runtime is heavy. If you don’t need the integration platform, you’re paying a lot for the gateway alone.
Apigee — analytics and monetization
Apigee’s strongest suits are deep analytics and built-in API monetization. If your APIs are products you bill for, Apigee gets you to revenue faster than anyone else on this list.
Best for: API-as-a-product companies, platforms with usage-based pricing, teams already invested in Google Cloud.
The catch: cost scales aggressively with traffic, and the platform pulls you deeper into GCP over time. Worth doing the three-year TCO maths before you commit.
Gravitee — the underrated challenger
Gravitee is the one most teams overlook. It’s event-native — first-class support for Kafka, MQTT, Server-Sent Events, and WebSockets — and the open-source tier ships features that are paid add-ons elsewhere. Pricing is flat, which makes budget planning honest.
Best for: event-driven architectures, async APIs, cost-conscious teams that still need an enterprise feature set.
The catch: smaller community than Kong or Apigee, and a few of the most advanced features sit behind the enterprise edition.
3. Side-by-side
| Capability | Kong | MuleSoft | Apigee | Gravitee |
|---|---|---|---|---|
| Raw performance | Excellent | Average | Strong | Strong |
| Cost at scale | Moderate | High | High | Low |
| Operator ergonomics | Moderate | Complex | Moderate | Friendly |
| Open-source tier | Partial | None | None | Full |
| Native monetization | No | No | Yes | No |
| Event-driven APIs | Limited | Limited | No | Yes |
The headline insight is that the market has effectively split in two. Kong, MuleSoft, and Apigee all assume an HTTP, request/response world. Gravitee is the one platform that treats async and streaming as first-class. If your roadmap has Kafka or MQTT on it, that distinction matters more than any feature checklist.
4. Should you build your own?
The short answer is no, and the long answer is probably still no.
A gateway looks deceptively simple from the outside — proxy a request, add a header, check a token. The complexity hides in the long tail: connection pooling under load, graceful reloads without dropping traffic, OIDC discovery, distributed rate limiting that doesn’t degrade under partition, plugin sandboxing, audit trails good enough for compliance review. A serious gateway is a multi-year platform investment.
That said, there are three scenarios where rolling your own is the right call:
- You need policy logic so specific to your product that no off-the-shelf plugin fits and you’d be forking a vendor’s Lua anyway.
- The gateway is part of the product you’re selling — i.e. you’re building Apigee, not buying it.
- You’re in a regulated environment where every line of code at the edge needs to be auditable, and the vendor’s plugin SDK is opaque enough to be a compliance risk.
If one of those describes you, a Node.js stack that punches well above its weight looks like this:
- Framework: Fastify
- Proxy:
@fastify/http-proxyfor HTTP,wsfor WebSocket pass-through - Rate limiting:
rate-limiter-flexiblebacked by Redis cluster - Auth:
josefor JWT verification,openid-clientfor full OIDC - Observability:
prom-clientfor metrics, OpenTelemetry for traces - Logging:
pinowith async transports
A reasonably tuned Fastify proxy on modern hardware will do 30k–50k req/sec per node. That’s enough for most internal platforms. If you need 100k+ on a single node, accept that Node is not the fastest proxy runtime — Envoy or a Go-based gateway will outperform it by a wide margin, and that’s the point at which “build your own” stops being a sensible answer.
5. The decision framework that actually works
The mistake I see teams make is treating gateway selection as a feature comparison. The features mostly converge over time. The thing that doesn’t converge is fit — for your traffic shape, your team’s skills, and your business model.
A better starting question:
| Your primary problem | Sensible default |
|---|---|
| Squeezing latency out of a high-traffic API | Kong |
| Stitching together legacy enterprise systems | MuleSoft |
| Selling APIs as a metered product | Apigee |
| Streaming, eventing, async-first platforms | Gravitee |
| Regulatory constraints or product-grade gateway | Build your own |
Pick the row that matches the problem you’re actually being paid to solve, and ignore the others. The vendor that wins the bake-off is rarely the one with the longest feature list — it’s the one that makes the problem you’re solving feel small.
6. Where the category is heading
Three shifts are reshaping what “API gateway” means over the next eighteen months.
LLM and AI gateways
Prompt routing, model fallbacks, token-budget enforcement, PII redaction at the edge — these are gateway concerns, not application concerns. Kong, Cloudflare, and a handful of new entrants are already shipping AI-specific gateway products. Expect this to be a checkbox feature across the major vendors by end of 2026.
Event-native everything
Kafka and MQTT are no longer specialist concerns. Gateways that treat HTTP as the only first-class protocol are increasingly behind. Gravitee got here first; the others are catching up.
Programmable edge with WASM
WASM plugins replace Lua and other gateway-specific scripting languages with portable, sandboxed modules you can write in Rust, Go, or TypeScript. This is the single most consequential shift in the category — it removes the language tax that’s slowed enterprise adoption of Kong and similar platforms.
Final thoughts
There is no winner in this category. There is only the gateway whose trade-offs match the work in front of you.
Pick on philosophy first, then on the specifics. Kong if performance and extensibility lead. Apigee if monetization and analytics lead. MuleSoft if integration breadth leads. Gravitee if events and cost lead. Build your own only if the platform is the product.
And whichever you pick, write down the boundary between gateway-owned policy and service-owned business logic before you ship. That contract is the thing that ages well — or doesn’t.