How to Choose the Right API Gateway for Your Architecture?

1. Why Re‑examine the Gateway Layer

During a microservice refactor the author discovered a "middle‑man" problem: the gateway accumulated over 300 handlers, requiring code changes in both the gateway and the business service for each new API. This indicated that aggregation and protocol adaptation responsibilities belong in the business domain, not in a separate gateway.

2. Four Gateway Architecture Patterns

The author and a senior WeChat backend engineer identified four common patterns:

Dedicated API Gateway (e.g., APISIX, Kong, Envoy, Traefik): provides authentication, rate‑limiting, gray‑release, protocol conversion, and circuit‑breaking via plugins; strengths are hot‑config updates, mature plugin ecosystem, and single‑point operation; weaknesses are stateless request‑level processing only, no cross‑service orchestration, and potential single‑point bottleneck.

Independent BFF Microservice (custom Go service): fully flexible, can implement any orchestration logic; however, adding an API requires changes in both the BFF and the business service, the BFF can become a "second monolith", and governance is scattered.

Framework Gateway (grpc‑gateway, go‑zero gateway): automatically generates HTTP‑to‑gRPC reverse‑proxy code from proto/IDL; advantages are zero hand‑written code and unified tech stack; disadvantages are 1:1 mapping only, no cross‑service aggregation, each service must expose an HTTP port, and custom HTTP behavior requires intrusive proto options.

Independent Gateway Microservice (WeChat Logicsvr) : splits the gateway into multiple binaries, each handling a specific business domain using the Svrkit framework; provides domain‑level aggregation without a separate orchestration layer, but requires a custom RPC framework that most teams lack.

3. Protocol Choice: HTTP for Front‑end, gRPC for Back‑end

HTTP/1.1 is text‑based, incurs large headers, requires new connections or Keep‑Alive, and adds latency in high‑density service‑to‑service calls due to connection‑pool management, JSON serialization, and lack of typed contracts. It is suitable for browsers because of native support, mature debugging tools, and CDN friendliness.

gRPC, built on HTTP/2 multiplexing and protobuf binary serialization, offers far better performance and strong‑typed contracts. Google uses gRPC for all internal service communication, but browsers cannot directly call gRPC; gRPC‑Web has limitations (no bidirectional streaming) and a less mature ecosystem.

Front‑end (HTTP/JSON)
  │  Browser native support, easy debugging, CDN friendly
  ▼
Gateway (protocol‑translation layer)
  │  HTTP → gRPC conversion, unified auth/ratelimit/gray‑release
  ▼
Back‑end (gRPC‑only)
  │  HTTP/2 multiplexing, protobuf contracts, high performance

The grpc‑transcode plugin becomes a key selection factor because it lets the gateway automatically translate HTTP/JSON to gRPC without the services being aware of HTTP.

4. WeChat’s Architecture Evolution (Logicsvr Pattern)

WeChat migrated through three stages:

Stage 1 – mmweb CGI container : all client APIs lived in a single module; .so coupling caused a single crash to bring down the whole process and slowed releases.

Stage 2 – Logicsvr independent gateway microservices : split into 8‑to‑dozens of binaries, each serving a domain‑specific CGI interface; achieved independent deployment, fault isolation, and decoupled iteration.

Stage 3 – WRMesh service mesh : combined Svrkit with a service mesh, separating framework from business, supporting thousands of services and tens of trillions of daily RPC calls.

The core idea is that each Logicsvr handles aggregation within its domain, relying on Svrkit for RPC, code generation, service discovery, rate‑limiting, and serialization.

5. Open‑Source Gateway Component Comparison

Performance benchmark (4 CPU × 8 GB, 100 k QPS):

APISIX – avg 6.7 ms, P99 32 ms

Envoy – avg 8.2 ms, P99 45 ms

Traefik – avg 12.1 ms, P99 68 ms

Configuration hot‑reload (100 route changes):

APISIX – 1.8 s (Admin API → etcd → hot‑load)

Envoy – 3.2 s (Gateway API → K8s controller)

Traefik – 5.7 s (static file reload)

Other dimensions (language, config store, hot‑reload mechanism, plugin count, gRPC‑transcode support, license) show APISIX leading in performance, hot‑update speed, and plugin ecosystem. Kong’s drawbacks are DB‑polling‑based hot‑reload (seconds) and gRPC‑transcode being a paid enterprise feature.

6. When BFF Is the Right Choice

Netflix is a classic BFF example because it serves > 1 000 device types, each with distinct API needs; therefore it maintains dedicated BFFs per client. For scenarios with only one or two front‑ends (e.g., internal admin panels), BFF adds little value.

Other companies’ practices confirm this rule: large multi‑device ecosystems benefit from BFF, while most other firms aggregate within the microservice layer.

7. Recommended Architecture

For most business scenarios the author recommends:

APISIX as the gateway

gRPC‑only microservices (no HTTP ports)

Domain‑level aggregation inside the microservices

Key decisions:

Move data aggregation into the microservice domain, exposing aggregated gRPC interfaces to eliminate the “modify two services for one feature” problem.

Unify on gRPC‑only; let APISIX’s grpc‑transcode plugin handle HTTP‑to‑gRPC translation, keeping the front‑end HTTP for compatibility and the back‑end gRPC for performance.

Avoid adding an independent orchestration layer (BFF or similar) unless multi‑device differences demand it.

When to Evolve Further

Significant multi‑device differences → APISIX route groups + multiple proto versions (no separate BFF needed).

Cross‑domain saga transactions → adopt a workflow engine (Temporal / Cadence) – not a gateway responsibility.

Thousands of tenants → Service mesh (Istio) + multi‑cluster deployment.

8. Conclusion

Choosing the wrong gateway pattern incurs far higher migration cost than swapping a specific product. Understanding why industry leaders selected their patterns (WeChat’s Logicsvr, Netflix’s BFF, ByteDance’s APISIX) is more valuable than the product name itself. Early, correct gateway selection saves massive refactoring effort and keeps the architecture scalable.