API Gateway vs Direct Service Calls — Real Trade-offs (from building microservices)

Most posts say: “Always put an API Gateway in front.”

That’s not advice. That’s a meme.

Reality: the right choice depends on your stage, your clients, and what you’re willing to operationally own. I’ve built microservice setups where direct calls were the only reason we shipped fast — and setups where skipping a gateway created a mess.

Here’s the decision, without fluff.

The 20‑second definition

• Direct calls: Service A calls Service B directly.

• API Gateway: Clients call the gateway; the gateway routes to services and handles cross-cutting concerns.

Why direct calls feel “right” (early on)

Direct calls are attractive because they remove ceremony:

• no routing config

• no extra deployment to maintain

• fewer failure points

• lower latency today

Example: direct call (FastAPI → FastAPI)

# orders_service -> calls payments_service directly
import httpx
async def charge_customer(order_id: str, amount: int):
    async with httpx.AsyncClient(timeout=5) as client:
        r = await client.post(
            "http://payments:8000/charge",
            json={"order_id": order_id, "amount": amount},
            headers={"X-Internal-Token": "..."}
        )
    r.raise_for_status()
    return r.json()

This is fast to build. You ship. You feel productive.

Then scale hits.

Where direct calls start hurting (the real pain)

1) Auth duplication (and drift)

Every service begins implementing its own auth rules. They won’t stay consistent.

2) Rate limiting becomes impossible to enforce

Service A rate limits one way, Service B another. Attackers love this.

3) Client complexity explodes

Your frontend starts doing orchestration:

• call auth

• call users

• call orders

• call payments

• merge responses

That’s not “microservices.” That’s clients doing backend work.

4) Observability becomes a detective story

Without centralized entry + tracing, debugging becomes:

“Where did this request die?”

And you waste hours.

What a gateway actually buys you

A gateway is basically a policy + routing layer.

Typical wins:

• single place for JWT validation / RBAC

• consistent rate limiting

• request shaping (BFF-style

• centralized logging + tracing headers

• simpler clients (one API surface)

Example: gateway routing (conceptual)

# Nginx as a simple gateway (illustrative)
location /api/orders/ {
  proxy_pass http://orders:8000/;
}
location /api/payments/ {
  proxy_pass http://payments:8000/;
}

Example: centralized auth at gateway (pseudo)

// Middleware at gateway (Next.js / Node / edge)
export function requireAuth(req) {
  const token = req.headers.get("authorization")?.replace("Bearer ", "");
  if (!token) throw new Error("Unauthorized");
// verify JWT once here
  const user = verifyJwt(token);
  req.user = user;
}

Now services can focus on business logic — not “security plumbing” 20 times.

What the gateway costs (don’t ignore this)

Here’s what tutorials conveniently skip:

• extra hop (latency)

• single chokepoint (bad config can break everything)

• ops burden (deploy, scale, monitor)

• risk of becoming a “gateway monolith” if you stuff business logic there

If you don’t have discipline, the gateway becomes the new monolith — just with better marketing.

The decision framework (use this, not vibes)

Choose direct calls when:

• you have 1 client (your own web app)

• you have few services (2–5)

• you’re still validating product/market fit

• speed > polish

• internal-only APIs

Choose an API Gateway when:

• you have multiple clients (web + mobile + partners)

• you need consistent auth + rate limiting + audit logs

• you expose public APIs

• observability is hurting (you can’t trace requests)

• the team grows (more owners → more inconsistency)

The pattern that usually wins: Hybrid

Most sane setups end up here:

• Gateway for external traffic (clients → gateway → services)

• Direct calls internally (service → service)

If internal communication gets complex, then you graduate to:

• async messaging (queues)

• service mesh (only when you can afford it)

My blunt takeaway

• A gateway is not a default requirement.

• Direct calls are not “wrong.”

• The real question is: where do you want complexity to live — in every service, or in one place?

If you’re early-stage, start simple.
If you’re scaling clients/security/traffic, centralize policy.

That’s the trade-off.

🔥 Found this blog post helpful? 🔥

If you enjoyed this article and found it valuable, please show your support by clapping 👏 and subscribing to my blog for more in-depth insights on web development and Next.js!

Subscribe here: click me

🚀 Follow me on:

• 🌐 Website: sagarsangwan.dev

• 🐦 Twitter/X: @sagar sangwan

• 🔗 LinkedIn: Sagar Sangwan

• 📸 Instagram: @codingbysagar

• ▶️YouTube: @codingbysagar

Your encouragement helps me continue creating high-quality content that can assist you on your development journey. 🚀