Microservices API Gateway Interview Questions and Answers

The API gateway is one of the first patterns interviewers reach for, because it reveals whether you understand the edge of a microservices system — where clients meet services. A good answer explains what the gateway centralizes and, just as importantly, what it must not absorb. This page covers the gateway questions asked at every level and the follow-ups about single points of failure and the BFF pattern.

What is an API gateway and why do you need one?

A single entry point in front of your services that handles cross-cutting concerns — routing, authentication, rate limiting, TLS termination, and sometimes aggregation — so clients do not have to know about or call dozens of services directly. Without it, every client hardcodes service locations and re-implements auth and throttling.

The core benefit is decoupling: clients depend on one stable contract while services split, merge, and move behind the gateway. It also becomes the natural place to enforce security and observability uniformly, instead of hoping every team does it consistently.

Interview note: Follow-up: "what problems does it introduce?" A potential single point of failure, an extra network hop, and a component that can become a bottleneck for teams if it accumulates logic. Naming the downsides is what makes the answer senior.

What responsibilities belong on the gateway — and which do not?

Belongs: routing, authentication/authorization, rate limiting and throttling, TLS termination, request/response transformation, caching, and observability. Does not belong: business logic, domain rules, or anything a single service should own.

The anti-pattern interviewers hunt for is the "smart gateway" stuffed with domain logic. That recreates a monolith at the edge, couples every team to the gateway's release cycle, and makes it a deployment bottleneck. Keep it thin and generic.

How does the gateway route requests to the right service?

By matching request attributes — path, host, headers, or method — to a route that forwards to a service, resolving the service's live instances through service discovery and balancing across them. Spring Cloud Gateway, Kong, and NGINX are common implementations.

# Spring Cloud Gateway route: path predicate -> discovered service
spring:
  cloud:
    gateway:
      routes:
        - id: orders
          uri: lb://orders-service   # lb:// resolves via service discovery
          predicates:
            - Path=/api/orders/**
          filters:
            - StripPrefix=1
            - name: RequestRateLimiter

The lb:// scheme is the tell that the gateway integrates with discovery and a load balancer rather than hardcoding host and port.

API gateway vs load balancer — what is the difference?

A load balancer spreads traffic across identical instances of one service, mostly at L4/L7 network level. An API gateway works at the application layer: it routes by path or content to different services and layers on auth, rate limiting, and aggregation. They are complementary — a gateway typically uses a load balancer beneath it to reach service instances.

Interview note: Trap: "aren't they the same?" No — a load balancer answers "which instance?"; a gateway answers "which service, and is this caller allowed, throttled, and authenticated?"

What is the Backend-for-Frontend (BFF) pattern?

A dedicated gateway per client type — one for web, one for mobile — each shaping responses to that client's exact needs, instead of a single general-purpose gateway. Mobile gets slim payloads; web gets richer ones; each evolves independently.

The problem BFF solves is over-fetching and awkward one-size-fits-all endpoints. The cost is more gateways to maintain, so you adopt it when client needs genuinely diverge, not by default.

How does the gateway handle authentication?

It authenticates once at the edge — validating a JWT or session, often via OAuth2/OIDC — and forwards a verified identity (a validated token or trusted headers) to downstream services, which then enforce authorization. Centralizing authentication avoids every service re-implementing token validation.

The nuance to raise: the gateway does coarse authentication; fine-grained authorization ("can this user edit this order?") usually stays in the owning service, because only it knows the domain rules.

Can the gateway aggregate responses from multiple services?

Yes — for a screen that needs data from three services, the gateway (or a BFF) can fan out, call them in parallel, and compose one response, saving the client multiple round trips. Useful for high-latency mobile clients.

Keep aggregation shallow and generic, though — heavy orchestration and business rules in the gateway is the smart-gateway anti-pattern again. For complex composition, a dedicated aggregation service or GraphQL layer is cleaner.

Interview note: Follow-up: "what if one of the three calls fails?" Apply per-call timeouts and return partial data with a degraded flag rather than failing the whole screen — the gateway must be resilient to any single downstream failing.

How do you keep the gateway from being a single point of failure?

Run several stateless gateway instances behind a load balancer, add health checks and auto-scaling, and protect every downstream call with timeouts and circuit breakers so a failing service cannot exhaust the gateway. Statelessness is key — any instance must serve any request so instances are freely replaceable.

How does the gateway enforce rate limiting?

It tracks request counts per client (by API key, user, or IP) against a limit over a window, using algorithms like token bucket or sliding window, and rejects with HTTP 429 when exceeded. In a multi-instance gateway the counters live in a shared store like Redis so the limit is global, not per instance.

What interviewers really test

Gateway questions check whether you understand the edge as a place for cross-cutting concerns — and whether you have the discipline to keep it thin. The candidates who impress name the responsibilities, name the anti-pattern (business logic on the gateway), and address the single-point-of-failure risk without being asked. Have a clear picture of how a request flows from client through gateway to service.

The gateway leans on two neighboring patterns, so pair this with the service discovery questions and the load balancing question set to complete the edge story. Reinforce the concepts with the microservices learning path, and rehearse routing and resilience trade-offs in a mock interview before facing them live.