API Gateway

Introduction

In a microservices world, clients (mobile apps, web apps, IoT devices) often need to talk to multiple services. Without a central entry point, every client must call each microservice directly — leading to tight coupling, security gaps, and complexity.

The API Gateway Pattern solves this problem by acting as the front door to all microservices. It routes requests, applies cross-cutting concerns (authentication, logging, caching), and simplifies client interaction.

Think of it as a reception desk in a corporate office: visitors don’t directly roam around to find employees — they check in at reception, which guides them to the right place.

Problem Statement

• Clients need data from multiple services.
• Without a gateway:
• • Clients must know the location (URL/IP) of each service.
  • More network calls = higher latency.
  • Security/authentication must be handled individually by each service.
  • Versioning and backward compatibility become harder.

Example:

• Mobile app wants user profile → Needs info from user-service, order-service, and payment-service.
• Without gateway → 3 direct calls from mobile → complex, chatty communication.

Concept Overview

Definition:
The API Gateway is a single entry point that sits between clients and backend microservices.

Core Idea:

• Client sends 1 request → Gateway routes/aggregates → responds with a simplified payload.
• Gateway handles cross-cutting concerns: security, logging, rate limiting, caching.

Diagram (simplified):

Client (Web/Mobile) ---> [ API Gateway ] ---> Microservices
|--> User Service
|--> Order Service
|--> Payment Service

When to Use

• Multiple clients (web, mobile, IoT) need access to microservices.
• Centralized handling of cross-cutting concerns.
• Aggregation of data from multiple services into one response.
• Need for client-specific APIs (different payloads for mobile vs web).

When to Avoid

• Very small systems (2–3 services, low traffic).
• Early prototyping where simplicity > scalability.
• If all clients directly trust a single service (rare case).

Architecture / Flow

1. Client makes API request → Gateway.
2. Gateway authenticates, validates request.
3. Gateway routes request to correct service(s).
4. Aggregates responses if needed.
5. Applies caching/logging/rate-limiting.
6. Sends simplified response back to client.

Implementation (Step-by-Step)

Technology Choices

• Nginx / Kong / Tyk / Apigee → popular open-source/commercial gateways.
• Spring Cloud Gateway (Java).
• Express.js + Node.js → DIY gateway.
• AWS API Gateway / Azure API Management / GCP Apigee → cloud managed.

Example: Node.js Express API Gateway

const express = require('express');
const proxy = require('http-proxy-middleware');

const app = express();

// Route: /users → User Service
app.use('/users', proxy.createProxyMiddleware({ target: 'http://localhost:5001', changeOrigin: true }));

// Route: /orders → Order Service
app.use('/orders', proxy.createProxyMiddleware({ target: 'http://localhost:5002', changeOrigin: true }));

// Route: /payments → Payment Service
app.use('/payments', proxy.createProxyMiddleware({ target: 'http://localhost:5003', changeOrigin: true }));

app.listen(3000, () => {
console.log("API Gateway running at http://localhost:3000");
});

Now clients only call http://localhost:3000 instead of directly calling each service.

Advantages

• Simplifies clients → only 1 entry point.
• Cross-cutting concerns centralized → logging, monitoring, security.
• Improved security → hide internal microservice details.
• Aggregation → reduce multiple calls into one.
• Easier versioning & evolution → clients remain stable while backend changes.

Disadvantages / Pitfalls

• Single point of failure (unless deployed redundantly).
• Increased latency (adds one extra network hop).
• Operational complexity → managing gateway rules, scaling gateway itself.
• Can become a bottleneck if not properly scaled.

Best Practices

• Deploy API Gateway in HA mode (clustered).
• Use caching for frequently accessed data.
• Enable rate limiting & throttling to protect services.
• Implement security policies (OAuth2, JWT, API keys).
• Keep gateway stateless → easy scaling.
• Combine with service discovery for dynamic routing.

Common Mistakes to Avoid

• Putting too much business logic in the gateway.
• Not monitoring gateway → blind to bottlenecks.
• Using gateway as a “catch-all” → leads to monolithic API Gateway (anti-pattern).

Comparison with Alternatives

• Direct Client → Microservice Calls: Simple but tightly coupled.
• Service Mesh: Focused on service-to-service communication (inside the cluster), while API Gateway handles client-to-service.
• BFF (Backend for Frontend): Variation of API Gateway tailored for specific client types.

Real-World Use Cases

• Netflix Zuul → pioneer of API Gateway.
• Amazon API Gateway → widely used in AWS serverless/microservices.
• Uber → uses API Gateways to handle millions of client requests daily.

Expert Tips 🔥

• Pair with Circuit Breaker + Retry + Timeout to improve resilience.
• Use GraphQL with Gateway for flexible client queries.
• For large systems, consider BFF approach to reduce payload size for mobile vs web.

Conclusion / Key Takeaways

The API Gateway Pattern is the front door to microservices.

• Use it when you need a single entry point for multiple services.
• Avoid overloading it with business logic.
• Always scale & monitor it to prevent becoming a bottleneck.