In modern system architectures, understanding data flow is crucial. Two fundamental concepts are north-south and east-west communications. Although both deal with APIs and services, they solve fundamentally different problems and require distinct tools. Below, we’ll explore why using API gateways for east-west traffic is considered an anti-pattern and suggest alternative architectures for these scenarios.

North-South Communication: The Gateway

North-south communication refers to all traffic that enters or leaves your infrastructure. It’s the conversation between an external client (such as a mobile application, a web browser, or a partner system) and your backends.

For these external requests to reach the correct services and return a response, they need to be managed by an entry point. This flow is classically handled by components like load balancers and reverse proxies.

However, for robust management, the most suitable solution is the combination of an API manager with an API gateway. These components are ideally responsible for managing and governing these exposures, handling security, rate limiting, authentication, and routing at the edge of your architecture.

East-West Communication: The Internal Conversation

East-west communication, on the other hand, is the traffic that happens within your infrastructure. It’s the interaction between different distributed services that need to collaborate, such as in:

• Microservices-based solutions
• Distributed applications with high integration needs
• Autonomous interfaces within the same network

In this scenario, the communication medium is even more critical. The internal network, even though more reliable than the internet, is never 100% stable. Failures can and will occur, compromising data exchange between services.

Strategies for East-West Communication

To ensure this internal communication is resilient, especially in microservices, several strategies can be adopted. The most common go beyond the service mesh:

• Service mesh: This is the most well-known modern approach. Communication is managed by sidecars that run alongside each microservice. The great advantage is that resilience logic (such as retries and circuit breakers) is abstracted from the application and moved to the sidecar, which is managed by the infrastructure.
• Asynchronous communication (messaging brokers): Here, data is shared asynchronously using tools like RabbitMQ or Kafka. Services publish events or messages without waiting for an immediate response. This approach offers native resilience — if a consuming service goes down, the message simply stays in the queue, eliminating synchronous dependencies.
• Smart client libraries: Before service meshes, this was the main strategy. The application itself includes libraries that handle network complexity. The Spring Cloud ecosystem is a classic example, providing features (based on libraries like Resilience4j) that implement essential patterns like circuit breakers and service discovery directly in the application code.

The Anti-Pattern: Why Not to Use an API Gateway for East-West Traffic

It’s tempting to think: “If I already have an API gateway, why not use it to manage all communication?” However, using a gateway (or an API manager) for east-west traffic is considered an anti-pattern.

An API gateway is built to handle requests from external clients, not for the internal, high-volume conversation between microservices. Using it for this creates three critical problems:

1. Unnecessary latency (hairpin traffic): When service A needs to talk to service B (which is on the same network), the request is forced to “go up” to the centralized gateway and then “come down” again. This adds unnecessary network hops to each internal call, multiplying latency and degrading performance.
2. High coupling: Microservices lose their autonomy. Instead of communicating directly (or through a light sidecar), they now depend on a centralized infrastructure component for internal tasks, violating the principle of low coupling.
3. Breakdown of fault isolation: The biggest benefit of microservices is fault isolation. By centralizing all internal communication in a gateway, you create a single point of failure (SPOF). If this gateway fails, no internal service will be able to communicate, causing a general outage — exactly what distributed architecture tries to avoid.

Using the Right Tool at the Right Time

You technically could use a gateway for internal communication, but you would be creating a slow, fragile, and difficult-to-scale architecture. The service mesh (and its alternatives) was explicitly created to solve the problems of east-west traffic efficiently and decentrally.

When using an API gateway, envision it as your system’s gatehouse, managing all external-to-internal (north-south) traffic. Conversely, a service mesh (or its alternatives) functions as the internal communication system, overseeing how services interact with each other (east-west traffic).

Technical Recommendation

Use the API gateway to expose your services to the external world, handling authentication by validating users and API keys at the entry (or JWT tokens when using the OAuth 2.0 protocol), routing external traffic (e.g., api.com/orders) to the correct microservice, and providing edge security by applying rate limiting and handling via SSL/TLS. It acts as a single “facade” for all your services.

Use a service mesh for complex internal communication between services, automating retries and circuit breakers for resilience, tracing complete requests through multiple internal services to find bottlenecks for observability, and automatically encrypting (mTLS) all conversations between your services for internal security (zero trust).

In summary, you use the gateway to receive the client’s call. You use the mesh (or a broker, or a library) to manage the chain of internal calls that this initial call provoked.