API gateway

One endpoint, several services

An API gateway is a centralized entry point between clients and application services. It acts as a reverse proxy. The client sends a request to the gateway, and the gateway routes that request to the appropriate backend.

Suppose a client calls /catalog/search and /orders/42. Gateway routing can send the first request to a catalog service and the second to an order service. The client only needs the gateway endpoint. A backend can be split, replaced, or moved while the client-facing route stays stable.

Wrong "A gateway combines every request with other requests."

Right Routing can forward one request to one backend. Aggregation is a separate behavior where one client operation causes calls to several backends and the gateway combines their responses.

What belongs at the edge

Gateways often handle concerns shared by many public APIs. Official gateway guidance lists authentication, TLS termination, mutual TLS, client rate limiting, logging, monitoring, and response caching among the functions that can be offloaded.

TLS termination means the inbound TLS connection ends at the gateway. One documented offloading design then sends HTTP to upstream servers. Protection for the gateway-to-service hop is therefore a separate choice in that design.

Wrong "Once TLS terminates at the gateway, every later network hop is encrypted."

Right TLS termination describes the client connection's endpoint. Inspect the upstream connection separately.

Keep business behavior in services

Offloading a shared check can remove repeated configuration from every public service. It also creates a common place to enforce a client rate limit or validate credentials. Microsoft explicitly advises against offloading business logic to the gateway.

A useful review question is whether a rule applies to traffic at the boundary or expresses the application's domain. Credential validation and client throttling fit the edge. Deciding whether an account may approve a particular refund depends on application behavior and belongs behind that edge.

Aggregation changes who coordinates the calls

An order-summary screen might need data from order, shipment, and customer-profile services. Without aggregation, the client calls each service and handles each failure. With gateway aggregation, the client makes one request. The aggregation layer calls the backends and assembles one response.

This reduces client-to-service round trips and hides backend decomposition from the client. It does not turn three backend operations into one. The calls still consume backend and gateway resources.

Wrong "Aggregation reduces three backend calls to one."

Right It reduces the calls made by the client. The gateway still fans out to the required backends.

The failure contract needs a written answer. If shipment times out, the endpoint can return a marked partial result when missing shipment data is acceptable. It can instead fail the whole request when the response must be complete. Official guidance calls for bounded timeouts and suggests circuit breaking, bulkheads, correlation IDs, and explicit partial-response handling.

Aggregation also has a boundary. Lightweight response assembly can live at a gateway. Microsoft recommends a dedicated aggregation service behind the gateway when the work has custom domain logic, complex transformations, different resource needs, or longer-running orchestration.

When a BFF earns its deployment

A backend for frontend, or BFF, handles requirements specific to one client interface. A mobile app and desktop application may get separate BFFs when their payload shapes, performance constraints, or release needs differ. The frontend team can own the BFF's release cadence and feature integration.

The cost is another service lifecycle, another network hop, and probable code duplication. If the interfaces make the same requests, sharing a backend may be the cleaner design. The Microsoft pattern also says a BFF should contain client-specific logic while cross-cutting monitoring and authorization are handled separately.

Wrong "BFF is another name for the one shared API gateway."

Right A gateway commonly owns shared edge policy and routing. A BFF exists to tailor behavior for a particular interface. One architecture can use a gateway in front of separate mobile and desktop BFFs.

The distinction is ownership as much as topology. Routing rules answer where a request goes. A BFF answers what one frontend needs from the backend-facing layer.

API gateway versus service mesh

The two layers overlap in proxy features, but their scope differs. An API gateway is a centralized client entry point. Istio describes a service mesh as a data plane of proxies that mediates communication between microservices, plus a control plane that configures those proxies.

An Istio ingress gateway sits at the edge of the mesh and applies mesh monitoring and route rules to traffic entering the cluster. Microsoft also lists a service-mesh ingress gateway as one API gateway option. That does not make every gateway product equivalent. Its guidance notes that a mesh ingress gateway can have weaker support than a dedicated API gateway for API productization, request transformation, web application firewall features, and global routing.

Wrong "Choose either an API gateway or a service mesh because they solve the same problem."

Right They can be composed. The client-facing layer can handle API policy and external routing while the mesh handles workload traffic, identity, authorization policy, and telemetry. A mesh ingress gateway may be the entry proxy when its feature set meets the API's requirements.

The gateway widens the failure domain

A single client endpoint is useful, but every routed API now depends on that path. Microsoft identifies both single-point-of-failure and bottleneck risks in its routing and aggregation patterns. It recommends multiple gateway instances for high availability, enough capacity to scale with demand, and load testing to catch cascading failures.

Wrong "One gateway hostname means one gateway process."

Right The hostname is a logical entry point. Multiple gateway instances can serve it. Redundancy removes the single-instance failure, provided the surrounding routing and dependencies also meet the availability target.

Fan-out makes dependency behavior part of gateway capacity. An aggregation request can occupy resources while it waits on several services. Timeouts bound that wait. Circuit breaking and bulkheads can limit the effect of an unhealthy dependency. Correlation IDs and distributed tracing let operators identify which backend caused a slow or partial response.

Central policy has a change cost

Routing rules, certificates, credential checks, and rate-limit configuration need a managed lifecycle. A gateway change can affect many services at once. Official guidance recommends automation for routing rules, certificates, allow lists, and security configuration as services are added or modified.

Keep the gateway's policy surface narrow. Shared edge controls belong there. Lightweight aggregation may fit. Domain workflows and complex orchestration should move behind it, where they can scale and fail independently of basic routing and TLS termination.