Do I need an API gateway for internal microservices traffic?

Not always.

For internal microservices-to-microservices traffic, an API gateway is usually not the default choice. It’s more commonly used for external client traffic entering the system.

When you usually do not need one

If services talk to each other internally and you only need:

• service discovery
• load balancing
• retries/timeouts
• mTLS / authn/authz
• observability

then a service mesh or direct service-to-service communication is often a better fit than an API gateway.

When an API gateway can make sense internally

Use one if you need a centralized place for:

• request/response transformation
• protocol translation
• aggregating multiple backend calls
• enforcing common policies at the edge of a trust zone
• exposing a stable internal facade to multiple consumers
• rate limiting between domains/teams
• versioned internal APIs for many clients

Common pattern

• External traffic: API gateway
• Internal east-west traffic: service mesh, sidecars, or direct service calls

Tradeoffs of using a gateway internally

Pros

• centralized control
• consistent auth/policy enforcement
• simpler client code

Cons

• extra hop/latency
• more operational complexity
• can become a bottleneck or single point of failure
• can hide service-to-service topology and complicate debugging

Rule of thumb

Ask:

1. Is this traffic crossing a trust boundary?
2. Do I need cross-cutting policy enforcement?
3. Do multiple internal clients need a shared stable API layer?

If the answer is mostly no, skip the gateway.

If you want, I can help you decide between API gateway vs service mesh vs direct calls for your specific setup.