Module 5 — Architecture

API Gateway

Single entry point for all your microservices. Authentication, routing, rate limiting in one place.

1The Hotel Concierge Analogy

Simple Analogy
Imagine a luxury hotel:
Without Concierge
You need to know which floor has the restaurant, where the spa is, how to book tours. Confusing!
With Concierge (API Gateway)
One person handles everything. "I want dinner" → they route you. "Book a tour" → they handle it. One point of contact.

2What is an API Gateway?

An API Gateway is a server that acts as the single entry point for all client requests. It handles cross-cutting concerns like authentication, rate limiting, and request routing—so your services don't have to.

Architecture Overview

Web
Mobile
Partner
→
API Gateway
Auth
Rate Limit
Routing
Logging
→
Users
Orders
Products
Payments

3Key Responsibilities

🔐Authentication & Authorization

Verify JWT tokens, API keys, OAuth. Reject unauthorized requests before they reach services.

Check JWT → Valid? Route to service : Return 401
🚦Rate Limiting

Prevent abuse. Limit requests per user/IP. Protect backend from traffic spikes.

100 requests/min per user. Exceeds? Return 429.
🔀Request Routing

Route /users/* to User Service, /orders/* to Order Service based on path, headers, etc.

/api/v2/users → user-service:3000/users
📝Logging & Monitoring

Central place to log all requests, measure latency, track errors across all services.

Log: request_id, user, endpoint, latency, status
🔄Protocol Translation

Accept REST from clients, convert to gRPC for internal services. Or GraphQL to REST.

Client: REST → Gateway → gRPC to services
📦Response Aggregation

Combine responses from multiple services into one. Reduce client round trips.

/dashboard = user info + recent orders + notifications
🔒SSL Termination

Handle HTTPS at gateway. Backend services can use simple HTTP internally.

Client ←HTTPS→ Gateway ←HTTP→ Services
💨Caching

Cache frequent responses. Reduce load on backend services.

GET /products/popular → cached for 5 mins

4Request Flow

Step-by-Step Request Flow

1
Client Request
Client sends request to api.example.com/orders/123
2
SSL Termination
Gateway decrypts HTTPS, now has plain HTTP request
3
Authentication
Extract JWT from header, verify signature, decode user
4
Rate Limit Check
Is user under their limit? If not, return 429
5
Route Selection
/orders/* matches Order Service at order-svc:3000
6
Request Modification
Add X-User-ID header, remove sensitive headers
7
Forward Request
Send to http://order-svc:3000/orders/123
8
Response Processing
Log response time, modify headers, return to client

5Popular API Gateways

GatewayTypeBest ForNotes
KongOpen SourceGeneral purpose, pluginsBuilt on Nginx, Lua plugins
AWS API GatewayManagedAWS ecosystemLambda integration, pay-per-request
NginxOpen SourceHigh performanceSimple routing, need custom auth
EnvoyOpen SourceService mesh, KubernetesUsed by Istio, advanced features
TraefikOpen SourceKubernetes, DockerAuto-discovery, Let's Encrypt

6Pros & Cons

Advantages

  • ✓ Single point for cross-cutting concerns
  • ✓ Simplifies client code (one endpoint)
  • ✓ Hide internal service structure
  • ✓ Central place for monitoring/logging
  • ✓ Easy to add new services

Disadvantages

  • ✗ Single point of failure (need HA)
  • ✗ Added latency (extra hop)
  • ✗ Can become bottleneck
  • ✗ Additional complexity to manage
  • ✗ Risk of becoming "god service"
Best Practice

Keep your API Gateway thin. It should route and apply policies, NOT contain business logic. If you're writing custom code in your gateway for specific endpoints, that logic probably belongs in a service.

7Key Takeaways

1API Gateway = single entry point for all client requests to your microservices.
2Handles cross-cutting concerns: auth, rate limiting, routing, logging, SSL.
3Popular options: Kong, AWS API Gateway, Nginx, Envoy, Traefik.
4Keep it thin—routing and policies only, no business logic.
5Must be highly available (it's a single point of failure).
6In interviews: mention along with load balancer, service mesh, and BFF pattern.