Client-Server and API Gateways

What we're doing: Trace one request through every layer between a mobile app and the service that handles it.

Mobile app calls: POST /api/checkout

1. DNS resolves api.example.com to a load balancer IP.
2. Load balancer picks one of 6 healthy API gateway instances.
3. API gateway validates the auth token, checks the caller's
   rate limit, and routes /api/checkout to the checkout service.
4. The checkout service (one of 12 running instances, chosen
   by an internal load balancer) executes the order logic.
5. The response travels back through the same chain.

3

The load balancer only picks an instance — it does not know what an "order" is.

5

The gateway is the layer that knows about auth and rate limits — the backend service does not repeat that logic.

8

Internal traffic gets load-balanced too — this is not a client-facing-only concern.

Why this works: Naming each layer explicitly is what lets a design conversation say precisely where a responsibility (auth, routing, rate limiting) lives, rather than leaving it ambiguous which component owns it.

What we're doing: Show a gateway centralizing auth and aggregation for a mobile dashboard that would otherwise need three separate calls.

Without a gateway, the mobile app makes 3 calls:
  GET user-service.internal/profile
  GET orders-service.internal/recent
  GET billing-service.internal/balance
Each over a separate mobile network round trip.

With an API gateway:
  GET api.example.com/dashboard
    → gateway checks the auth token once
    → gateway calls all three internal services
    → gateway merges the three JSON bodies into one
  Mobile app makes 1 call, 1 round trip, gets everything.

6

The client no longer needs to know three internal service hostnames.

7

Auth is checked exactly once at the gateway, not three times by three services.

9

One round trip over a mobile network is the entire point — three round trips on a slow connection is visibly slower.

Why this works: Aggregation at the gateway trades three client round trips (each paying full mobile-network latency) for one, and moves auth/rate-limiting out of every individual service into a single, auditable place.

What we're doing: Show a credit-limit rule migrating from the gateway (where it does not belong) to the owning service.

Before: gateway rejects large orders itself
  gateway.use((req, res, next) => {
    if (req.body.total > req.user.creditLimit) {
      return res.status(402).send('over credit limit');
    }
    next();
  });
  // the orders service never even sees a rejected
  // order, and has no idea this rule exists

After: gateway only routes; orders service decides
  gateway.route('/orders/*', ordersService);
  // inside ordersService:
  if (order.total > customer.creditLimit) {
    return rejectOrder(order, 'over_credit_limit');
  }
  // the rule lives exactly once, in the service
  // that owns "orders" and "credit limits"

3

This looks convenient — one place to enforce the rule — but it means the orders service is no longer the source of truth for its own domain.

15

Moving the rule here means the orders service can be tested, deployed and understood without needing to know the gateway exists.

Why this works: A rule enforced at the gateway is invisible to the service it is actually about — anyone reading the orders service's code sees no credit-limit check at all, because it silently happens somewhere upstream.