What is an API Gateway?

An API Gateway is a single entry point through which clients access multiple backend services or Microservices.

Instead of the client directly communicating with every Microservice:

Without API Gateway

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

the client communicates with the API Gateway:

With API Gateway

                    ┌──→ Product Service
                    │
Client → API Gateway├──→ Order Service
                    │
                    ├──→ Payment Service
                    │
                    └──→ Customer Service

The Gateway receives the request, determines the appropriate backend service, forwards the request, and returns the response to the client.

2. Why Do We Need an API Gateway?

Imagine an e-commerce application containing:

Product Service
Order Service
Payment Service
Inventory Service
Customer Service
Shipping Service

Without an API Gateway, the frontend may need to know all service addresses:

https://product.company.com
https://order.company.com
https://payment.company.com
https://inventory.company.com

This creates several problems:

Client knows the internal architecture
Backend URLs are exposed
Authentication may be repeated
Rate limiting may need to be implemented repeatedly
Routing becomes harder to manage
Changing service locations can affect clients
Clients may need to call many services

An API Gateway hides this complexity.

Client
   |
   | https://api.company.com
   ↓
API Gateway
   |
   ├── /products → Product Service
   ├── /orders   → Order Service
   ├── /payments → Payment Service
   └── /shipping → Shipping Service

The client only needs to know:

https://api.company.com

3. Purpose of API Gateway

The main purpose is to provide a central entry point and routing layer between clients and backend services.

It can also centralize cross-cutting concerns such as:

                 Client
                    |
                    ↓
              API Gateway
                    |
       ┌────────────┼─────────────┐
       │            │             │
   Authentication  Routing    Rate Limiting
       │            │             │
       └────────────┼─────────────┘
                    ↓
               Microservices

Depending on the gateway product and architecture, it may handle:

Request routing
Authentication/authorization
Rate limiting
Load balancing integration
SSL/TLS termination
Logging
Monitoring
Request/response transformation
Caching
Response aggregation

4. How Does an API Gateway Work?

Suppose the client sends:

GET https://api.company.com/products/101

Step 1 — Request reaches Gateway

Client
   |
   | GET /products/101
   ↓
API Gateway

Step 2 — Gateway matches the route

It has routing configuration conceptually like:

/products/* → Product Service

/orders/*   → Order Service

/payments/* → Payment Service

Step 3 — Gateway forwards the request

Client
   |
   ↓
API Gateway
   |
   ↓
Product Service

Step 4 — Microservice processes it

Product Service
      |
      ↓
Product Database

Step 5 — Response returns through Gateway

Product Service
      |
      ↓
API Gateway
      |
      ↓
Client

The client doesn't need to know where the Product Service is actually hosted.

5. API Gateway in Microservices

A typical architecture might look like:

                  Angular / Mobile
                         |
                         ↓
                    API Gateway
                         |
          ┌──────────────┼──────────────┐
          ↓              ↓              ↓
     Product API     Order API      Customer API
          |              |              |
          ↓              ↓              ↓
      Product DB      Order DB      Customer DB

Internal Microservice communication may still happen independently:

Order Service
     |
     | gRPC / REST / Messaging
     ↓
Inventory Service

The API Gateway doesn't necessarily need to participate in every internal service-to-service call.

6. Request Routing

One of the Gateway's most important responsibilities is routing.

For example:

/api/products
      ↓
Product Service


/api/orders
      ↓
Order Service


/api/customers
      ↓
Customer Service

From the client perspective:

https://api.jntech.in/api/products
https://api.jntech.in/api/orders
https://api.jntech.in/api/customers

But internally they could be:

Product Service  → http://product-service:8080
Order Service    → http://order-service:8080
Customer Service → http://customer-service:8080

The Gateway hides these internal locations.

7. Authentication and Authorization

Instead of every request reaching a Microservice before basic authentication is checked, a gateway can participate in authentication.

Client
   |
   | JWT
   ↓
API Gateway
   |
Validate Token
   |
   ├── Invalid → 401
   |
   └── Valid
         ↓
    Microservice

However, backend services should still enforce authorization appropriate to their own security boundary rather than assuming the gateway makes every internal request trustworthy.

8. Rate Limiting

The Gateway can limit excessive traffic.

Example:

Client
   |
   | 1000 requests/sec
   ↓
API Gateway
   |
Rate Limiter
   |
   ↓
Allowed requests
   |
   ↓
Microservice

This helps protect backend services from excessive traffic.

9. Load Balancing

Suppose Product Service has three instances:

Product Service

Instance 1
Instance 2
Instance 3

Requests need to reach healthy instances.

Conceptually:

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

An important distinction:

API Gateway and Load Balancer are not the same thing.

The Gateway primarily handles API-level routing and policies, while load balancing distributes traffic among available service instances. Some gateway products can also perform load-balancing functions.

10. Response Aggregation

Sometimes one frontend screen requires information from several Microservices.

For example:

Product Details Page

Product information
Price
Inventory
Reviews

Without aggregation:

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

A Gateway or a dedicated backend-for-frontend/aggregation service can sometimes combine them:

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

This can reduce client-side orchestration, although too much business logic in the Gateway should generally be avoided.

11. API Gateway Technologies

For ASP.NET Core/Microservices environments, examples include:

YARP (Yet Another Reverse Proxy)
Ocelot
Azure API Management
AWS API Gateway
Kong
NGINX
Envoy

For a .NET-centric custom gateway/reverse-proxy layer, YARP is an important technology to know.

12. Advantages

Single Entry Point

Clients communicate through one public endpoint.

Hides Internal Architecture

Clients don't need to know individual Microservice locations.

Centralized Routing

/products → Product Service
/orders   → Order Service

Centralized Cross-Cutting Concerns

Depending on the gateway:

Authentication
Rate limiting
Logging
Caching
TLS termination
Request transformation

Easier Backend Changes

Backend service locations can change without necessarily changing the client-facing API.

Security Boundary

Internal service addresses can remain private rather than being directly exposed to external clients.

13. Disadvantages

Additional Complexity

You introduce another infrastructure component.

Additional Network Hop

Client → Gateway → Service

instead of:

Client → Service

This can add some latency.

Potential Bottleneck

Poor gateway design or insufficient scaling can make it a performance bottleneck.

Failure Point

If you run only one Gateway instance:

Client
   ↓
Gateway ❌
   ↓
Services

even healthy services may become inaccessible externally.

Therefore, production gateways are normally deployed with multiple instances/high availability.

Configuration Complexity

Routing, authentication, certificates, observability, resiliency, and deployment all need proper management.

14. API Gateway vs Load Balancer

This is a common interview question.

API Gateway	Load Balancer
API-level entry point	Traffic distribution component
Routes based on APIs/routes	Distributes traffic across instances
Can authenticate requests	Usually not application authorization
Can perform rate limiting	Primarily balances traffic
Can transform requests	Usually less application-aware
Can aggregate APIs	Usually doesn't aggregate responses

They are often used together:

Internet
   |
   ↓
Load Balancer
   |
   ↓
API Gateway Instances
   |
   ↓
Microservices

Exact topology depends on the platform.

15. API Gateway vs Service-to-Service Communication

Another important distinction:

External Request

Angular
   ↓
API Gateway
   ↓
Order Service

Internal communication could be:

Order Service
   |
   ├── gRPC ──→ Inventory Service
   |
   └── Message ──→ Notification Service

You generally don't need to force all internal Microservice communication through the external API Gateway.

16. Key Points

For interviews, remember:

API Gateway provides a single entry point for APIs.
It hides internal Microservice addresses from clients.
Its primary responsibility is request routing.
It can centralize authentication, rate limiting, logging, transformations, and other policies.
It is commonly used in Microservices Architecture.
API Gateway and Load Balancer have different responsibilities.
A gateway must be highly available to avoid becoming a single point of failure.
Avoid putting excessive business logic inside the Gateway.
Internal Microservices may communicate directly using REST/gRPC or indirectly through messaging.

Interview Questions & Answers

Q1. What is an API Gateway?

Answer:
An API Gateway is a single entry point between clients and backend Microservices. It receives client requests, applies configured policies, routes requests to the appropriate service, and returns the response.

Q2. Why do we need an API Gateway?

Answer:
It hides internal Microservice details from clients and centralizes concerns such as routing, authentication, rate limiting, logging, and request transformation.

Q3. Is API Gateway the same as Load Balancer?

Answer:
No. An API Gateway focuses on API routing and API-level policies, while a Load Balancer primarily distributes traffic across multiple instances. Some products can perform both functions.

Q4. Can API Gateway become a single point of failure?

Answer:
Yes, if only one instance exists. In production, gateways should generally be deployed redundantly and scaled appropriately.

Q5. Should Microservices communicate with each other through the API Gateway?

Answer:
Not necessarily. The Gateway is commonly used for external client traffic. Internal services can communicate directly using REST/gRPC or asynchronously through messaging.

Q6. What API Gateway can we use with ASP.NET Core?

Answer:
Common options include YARP, Ocelot, Azure API Management, Kong, NGINX, Envoy, and cloud-provider gateways. The choice depends on infrastructure and requirements.

Interview-Ready Answer

An API Gateway is a single entry point between clients and Microservices. Instead of exposing every Microservice directly, clients send requests to the Gateway, which routes them to the appropriate service. It can also handle cross-cutting concerns such as authentication, rate limiting, logging, TLS termination, and request transformation. In production, the Gateway should be highly available and should generally avoid containing core business logic.

API Gateway