MicroservicesAPI GatewayRequest RoutingDistributed Systemsjunior level

The API Gateway at the Edge

the question

What does an API gateway do in a microservices architecture, and why would you put one in front of your services?

what they're testing: The interviewer is checking whether you understand how an edge layer decouples clients from service topology while concentrating cross-cutting concerns and operational risk.

a strong answer

An API gateway gives external clients one entry point and routes each request to the appropriate service. Clients call the public API instead of tracking service addresses, so teams can change the internal service layout without exposing that topology to every client. The gateway is a reverse proxy at the edge, not a replacement for business logic or service-to-service messaging.

Depending on the product, the gateway can authenticate requests, terminate TLS, enforce rate limits, add correlation data, cache responses, or transform traffic. It can also send one client request to several services and combine the results, which can reduce client round trips. Routing is the foundation; the extra features should match the system's actual needs.

The trade-off is an extra network hop and another component on the critical path. The gateway must be monitored, scaled, and made highly available. Keep domain decisions in the services and keep custom gateway logic small. A single gateway can become a bottleneck or a coordination-heavy monolith, so separate gateways or backends for frontends may fit systems with distinct client needs or business boundaries. For a small system, direct client access can still be simpler.

Where people slip

the tempting wrong answer, and what's actually true

Every call between microservices should pass through the API gateway.
The gateway normally handles client ingress, while internal service-to-service communication can use its own routing and protocols.
A microservices system should always have one gateway in front of every service.
A gateway is optional, especially in a small system. Larger systems can also use multiple gateways split by client type or business boundary instead of one gateway for everything.
Adding a gateway removes the single point of failure at the edge.
A gateway adds a possible failure point and bottleneck, so it must be deployed and scaled for high availability.
The gateway should own the business workflows that span downstream services.
The gateway can aggregate responses, but domain workflows belong in application services. Putting substantial domain orchestration in the gateway couples services and can turn it into a monolith.

If they push further

How is an API gateway different from a load balancer?

A load balancer primarily distributes traffic across backend instances, while an API gateway routes at the API level and can enforce policies such as authentication, throttling, and transformations. Some gateway products also load balance.

How do you stop the gateway from becoming a single point of failure?

Use a managed gateway with documented availability or run multiple self-hosted instances behind a load balancer. Scale and monitor the gateway, and keep custom logic small. Redundancy reduces the risk, but the gateway remains a critical-path dependency.

When would you use a backend for frontend instead of one shared gateway?

Use separate client-facing gateways when mobile, web, or partner clients need materially different APIs or aggregation. Align ownership with those client or business boundaries so one gateway does not collect every concern.

Sources

Now answer it yourself.

Reading a strong answer is easy. Producing one under pressure is the skill the interview tests. Gapmap grades your answer against the same bar an interviewer would.

was this useful?

beta

The interviewer part is in the works.

The diagnostic, personal maps, and AI mock interviews are being finished right now. The notes stay free either way. Leave an email and you'll get the first-cohort invite, plus a month of Pro when it opens.