Why Misusing API Gateways and Service Registries Hurts Your Microservices

When working on consulting projects I often encountered a classic misuse of API gateways and service registries, and many teams still repeat the same mistakes.

In a microservice architecture an API gateway is typically the single entry point for exposing services, handling cross‑cutting concerns so that business services can focus on domain logic. Inside the system, services discover each other via a registration center and client‑side load balancing.

The combined role of the registration center and API gateway includes two main functions:

API gateway discovers all backend services through the registration center to provide dynamic proxying.

Backend service clusters discover each other via the registration center and invoke directly, usually with frameworks such as Ribbon or Feign.

The problematic pattern illustrated below uses two gateways—one for external traffic and another for internal traffic. The internal gateway acts as a proxy, routing calls through a second‑level domain like http://service-name.didispace.com/api-path instead of using the service name directly.

This approach defeats the purpose of a registration center: the registry only provides service discovery for the two gateways, and each service could simply register its address with the gateway, eliminating the need for the registry altogether. Moreover, every internal call incurs an extra hop through the internal gateway, increasing deployment overhead and latency.

The recommended practice is to let the API gateway manage external exposure only, while internal service‑to‑service communication should rely on the registration center plus client‑side load balancing. Adding an extra proxy layer raises cost and reduces performance.

An internal gateway may be justified only when a very large cluster with thousands of services is maintained by many independent teams, and a clear boundary is needed for access control and management. Otherwise, a simpler architecture is more stable.

Further Reading

Unconventional Microservice Refactoring: Distributed Monolith

Spring Cloud resources: https://blog.didispace.com/spring-cloud-learning/

Microservice resources: https://blog.didispace.com/micro-serivces-arch/