Why Gateways and Meshes Exist

The same chores in every service

When a system grows from one application into dozens of microservices, every service needs the same chores: authentication, TLS, rate limiting, logging, retries, timeouts, routing. Writing them in each service, in several languages, produces inconsistent and buggy copies. Two infrastructure layers take these chores out of application code. An API gateway sits at the edge and handles north-south traffic (from outside clients into the system). A service mesh handles east-west traffic (service-to-service calls inside), usually with a small proxy next to each service. Together they give a consistent place to enforce security, resilience and observability without changing every service.

Edge traffic and internal traffic

A gateway controls traffic coming into your system; a mesh controls traffic between your services.

A building's reception and its corridors

The reception desk checks visitors and directs them to the right office (gateway). Inside, badge readers on each door control who may move between offices and log every entry (mesh).

Do not add them too early

A single application or a handful of services rarely needs a mesh. Start with a simple reverse proxy or a managed gateway and add more infrastructure only when you can name the problem it solves.

Quick check: What does "east-west" traffic mean?

• Traffic between two data centres only
• Requests from the internet to the edge
• Service-to-service calls inside the system
• Email traffic