Junior Level

API Gateway is the single entry point into a microservice system. All requests from clients go through it.

Client -> API Gateway -> Service A
                      -> Service B
                      -> Service C

API Gateway responsibilities:

1. Routing — direct the request to the right service
2. Authentication — verify the token once
3. Rate limiting — limit requests (Rate Limiting — restricting the number of requests from one client)
4. Logging — log all requests
5. CORS — handle cross-origin requests (CORS — Cross-Origin Resource Sharing, a browser security mechanism)

---

Middle Level

When NOT to use API Gateway

• Internal microservices not facing external clients
• 2-3 services — direct calls are simpler
• Latency-critical systems — extra hop adds delay

API Gateway functions

1. Request routing: /api/users -> User Service
                    /api/orders -> Order Service

2. Authentication: verify JWT token

3. Rate limiting: 100 requests per minute per client

4. Caching: cache responses

5. Response transformation: transform format

6. Request aggregation: gather data from multiple services

Examples

• Spring Cloud Gateway
• Kong
• Nginx
• AWS API Gateway
• Zuul (Netflix)

Common mistakes

1. Gateway bottleneck:

   All requests through one Gateway -> single thread
   Solution: horizontal scaling of Gateway
   

---

Senior Level

Architectural Trade-offs

Gateway	BFF (Backend for Frontend)
One Gateway is simpler to operate (one component to monitor).	Separate for each client
BFF is more flexible: each client (web, mobile, API) gets its own optimized endpoint.	More infrastructure

Production Experience

Spring Cloud Gateway:

@Bean
public RouteLocator routes(RouteLocatorBuilder builder) {
    return builder.routes()
        .route("user-service", r -> r
            .path("/api/users/**")
            .filters(f -> f
                .circuitBreaker(config -> config
                    .setName("userCircuitBreaker"))
                .requestRateLimiter(config -> config
                    .setRateLimiter(redisRateLimiter)))
            .uri("lb://user-service"))
        .route("order-service", r -> r
            .path("/api/orders/**")
            .uri("lb://order-service"))
        .build();
}

// When the circuit breaker opens — the client sees 503 Service Unavailable // (or a cached response, if configured).

Best Practices

✅ Gateway without business logic
✅ Circuit breaker on Gateway
✅ Rate limiting
✅ Monitoring and logging
✅ Health checks

❌ Business logic in Gateway
❌ Single Gateway instance
❌ Without rate limiting

---

Interview Cheat Sheet

Must know:

• API Gateway — single entry point, routes requests to microservices
• Responsibilities: routing, authentication, rate limiting, logging, CORS
• Gateway should NOT contain business logic
• Circuit breaker on Gateway protects from cascade failure
• BFF (Backend for Frontend) — separate Gateway per client (web, mobile)
• Horizontal scaling of Gateway is mandatory (not a single instance)
• Popular: Spring Cloud Gateway, Kong, Nginx, AWS API Gateway

Common follow-up questions:

• When NOT to use Gateway? Internal services, 2-3 services, latency-critical systems.
• Gateway vs BFF? Gateway — one for all, BFF — separate per client, more flexible but more infrastructure.
• How to scale Gateway? Horizontally + load balancer in front.
• What if Gateway goes down? The entire system is unavailable — need HA deployment.

Red flags (DO NOT say):

• “Gateway is the best place for business logic” — no, only routing and cross-cutting concerns
• “One Gateway instance is enough” — this is a single point of failure
• “Rate limiting is not needed” — protection from abuse is mandatory
• “Gateway adds negligible latency” — it adds a hop, important for latency-critical systems

Related topics:

• [[7. What is Service Discovery and why is it needed]]
• [[8. What is the difference between client-side and server-side discovery]]
• [[23. How to implement authentication and authorization in microservices]]
• [[5. What is Circuit Breaker pattern]]
• [[15. How to organize communication between microservices]]