Why Do We Need an API Gateway in Microservices?

In Microservices Architecture, an API Gateway provides a single entry point for clients and hides the complexity of multiple backend services.

1. What Problem Does It Solve?

Suppose an e-commerce application has these Microservices:

Product Service
Order Service
Payment Service
Inventory Service
Customer Service

Without an API Gateway:

                  ┌──→ Product Service
                  ├──→ Order Service
Client ───────────├──→ Payment Service
                  ├──→ Inventory Service
                  └──→ Customer Service

The client must know:

• Address of every service
• Which service handles which request
• Authentication requirements
• Changes to service URLs
• How to handle multiple backend calls

This creates tight coupling between the client and Microservices.

2. API Gateway Solves This

With an API Gateway:

Client
   |
   | Single URL
   ↓
API Gateway
   |
   ├──→ Product Service
   ├──→ Order Service
   ├──→ Payment Service
   ├──→ Inventory Service
   └──→ Customer Service

The client only communicates with:

https://api.company.com

The Gateway determines which Microservice should receive each request.

3. Main Reasons We Need an API Gateway

1. Single Entry Point

Instead of exposing many service URLs:

product.company.com
order.company.com
payment.company.com
inventory.company.com

the client uses one endpoint:

api.company.com

This simplifies client applications.

2. Hide Internal Microservices

The client doesn't need to know where services actually run.

Client
   ↓
API Gateway
   ↓
Internal Network
   |
   ├── product-service:8080
   ├── order-service:8080
   └── payment-service:8080

Services can be moved or scaled without necessarily changing the public client-facing API.

3. Centralized Routing

The Gateway can route requests based on paths.

/api/products/*
        ↓
Product Service

/api/orders/*
        ↓
Order Service

/api/payments/*
        ↓
Payment Service

For example:

GET /api/products/101

is routed to:

Product Service

while:

POST /api/orders

is routed to:

Order Service

4. Centralized Authentication

Instead of performing the same basic authentication handling at every public entry point:

Client
  ↓
JWT Token
  ↓
API Gateway
  ↓
Validate Authentication
  ↓
Microservice

The Gateway can reject invalid requests before they reach backend services.

However, individual Microservices should still enforce the authorization rules relevant to their own resources.

5. Rate Limiting

The Gateway can protect backend services from excessive requests.

Client
   |
   | 10,000 requests
   ↓
API Gateway
   |
Rate Limiting
   |
   ↓
Allowed Traffic
   |
   ↓
Microservices

For example:

Maximum: 100 requests/minute/client

Requests beyond the configured limit can be rejected, commonly with:

429 Too Many Requests

6. Load Balancing / Service Discovery Integration

Suppose Order Service has three instances:

Order Service

Instance 1
Instance 2
Instance 3

The gateway/platform can route traffic through service discovery or load-balancing infrastructure:

API Gateway
    |
    ↓
Service Discovery / Load Balancer
    |
    ├──→ Order Instance 1
    ├──→ Order Instance 2
    └──→ Order Instance 3

This becomes particularly important when Microservices are dynamically scaled.

7. Logging and Monitoring

Instead of relying only on separate entry-point logs:

Product → Logs
Order   → Logs
Payment → Logs

the Gateway can capture information about incoming API traffic:

Client
   ↓
API Gateway
   |
   ├── Request Logging
   ├── Metrics
   └── Correlation / Trace Information
   ↓
Microservices

Backend services still need their own application logs and distributed tracing.

8. Request and Response Transformation

The Gateway can sometimes transform requests before forwarding them.

For example, the external API might expose:

/api/products

while internally the service expects:

/internal/v2/catalog/products

Conceptually:

Client
   ↓
/api/products
   ↓
API Gateway
   ↓
Transform Route
   ↓
/internal/v2/catalog/products

This helps separate the public API contract from some internal implementation details.

9. Response Aggregation

Suppose a Product Details page requires:

Product Information
Price
Inventory
Reviews

Without aggregation:

Client
 ├──→ Product Service
 ├──→ Pricing Service
 ├──→ Inventory Service
 └──→ Review Service

An aggregation layer can potentially provide:

Client
   |
   ↓
Gateway / Aggregator
   |
   ├──→ Product Service
   ├──→ Pricing Service
   ├──→ Inventory Service
   └──→ Review Service
   |
   ↓
Combined Response

This reduces the number of calls the client needs to coordinate.

Complex business orchestration, however, is usually better placed in an appropriate backend service rather than turning the Gateway into a large business-logic layer.

4. Without vs With API Gateway

Without Gateway

Angular
  |
  ├──→ Product API
  ├──→ Order API
  ├──→ Payment API
  ├──→ Customer API
  └──→ Inventory API

The frontend becomes aware of many backend services.

With Gateway

Angular
   |
   ↓
API Gateway
   |
   ├──→ Product API
   ├──→ Order API
   ├──→ Payment API
   ├──→ Customer API
   └──→ Inventory API

This gives the frontend a more stable and controlled API boundary.

5. Advantages

An API Gateway provides:

• Single entry point
• Simplified frontend communication
• Centralized routing
• Reduced exposure of internal service topology
• Authentication at the edge
• Rate limiting
• Request/response transformation
• Centralized API traffic logging
• Integration with service discovery/load balancing
• Optional response aggregation
• Easier management of external API policies

6. Disadvantages

API Gateway also introduces some drawbacks:

Additional Complexity

Another infrastructure component must be configured, deployed, secured, and monitored.

Additional Network Hop

Client → Gateway → Microservice

This introduces some additional latency.

Potential Bottleneck

If poorly designed or undersized, the Gateway can become a performance bottleneck.

Single Point of Failure

A single Gateway instance can create:

Client
   ↓
Gateway ❌
   ↓
All APIs inaccessible

Therefore production environments normally deploy gateways with multiple instances and high availability.

7. Key Points

For interviews, remember:

API Gateway = Single entry point for Microservices.

Its major responsibilities can include:

API Gateway
   |
   ├── Routing
   ├── Authentication
   ├── Rate Limiting
   ├── Logging / Metrics
   ├── Transformation
   ├── Load-balancing integration
   └── Aggregation

Most importantly:

Don't put all business logic inside the API Gateway.

Its primary role is managing and controlling API traffic.

Interview Questions & Answers

Q1. Why do we need an API Gateway in Microservices?

Answer:
An API Gateway provides a single entry point for clients and hides the internal Microservice structure. It centralizes routing and can handle concerns such as authentication, rate limiting, logging, and request transformation.

Q2. Can Microservices work without an API Gateway?

Answer:
Yes. An API Gateway is not mandatory. Clients can communicate directly with services, but as the number of services and cross-cutting requirements increases, a Gateway can simplify client communication and API management.

Q3. Does an API Gateway improve security?

Answer:
It can improve the external security boundary by centralizing authentication, TLS termination, rate limiting, and other policies. Backend services should still implement appropriate authorization and internal security controls.

Q4. Is API Gateway a Load Balancer?

Answer:
No. A Load Balancer primarily distributes traffic across multiple instances, while an API Gateway provides API-level routing and policies. Some gateway products also include load-balancing capabilities.

Q5. Should all Microservice-to-Microservice calls go through the API Gateway?

Answer:
Usually, no. The API Gateway is commonly the entry point for external client traffic. Internal services can communicate through REST, gRPC, or asynchronous messaging depending on the requirement.

Interview-Ready Answer

We need an API Gateway in Microservices to provide a single entry point for clients and hide the complexity of multiple backend services. It routes requests to the appropriate Microservice and can centralize cross-cutting concerns such as authentication, rate limiting, logging, TLS termination, and request transformation. It also reduces coupling between clients and the internal service topology. However, the Gateway should be highly available and should generally avoid containing core business logic.