SYS ARCHITECTLearning Platform
Settings
Theory

API Gateway

📋 Overview

An API Gateway acts as a single entry point (reverse proxy) for all client requests to a backend system. It decouples the client interface from the internal microservices architecture, providing a centralized location to manage cross-cutting concerns such as security, routing, and observability.


🏗️ Core Principles & Characteristics

  • Request Routing: Maps public URLs to specific internal microservice endpoints (e.g., /orders -> Order Service).
  • Security & Auth: Centralized validation of JWTs, OAuth tokens, or API keys at the "edge" before requests reach internal services.
  • Protocol Translation: Translates between different protocols, such as converting external REST/JSON calls to internal gRPC or AMQP.
  • Aggregation (Fan-out): A single client request can trigger multiple downstream calls, with the gateway aggregating the results into one response.
  • Rate Limiting & Throttling: Protects backend services from traffic spikes and DDoS attacks.
  • Circuit Breaking: Prevents cascading failures by stopping traffic to downstream services that are failing or under heavy load.

⚖️ Trade-offs: Pros & Cons

  • Pros:
    • Simplified Client Logic: Clients only need to know one URL and one auth mechanism.
    • Security Hardening: Reduces the attack surface by hiding internal microservices.
    • Reduced Over-fetching: Gateway can filter or transform responses to return only what the client needs.
  • Cons:
    • Single Point of Failure: If the gateway goes down, the entire system is unreachable.
    • Increased Latency: Every request adds an extra network hop.
    • Complexity: Managing routing rules, certificates, and scaling the gateway itself adds operational overhead.

🌍 Real-World Implementation

  • Cloud Native: AWS API Gateway, Azure API Management, Google Cloud Endpoints.
  • Open Source: Kong, Tyk, KrakenD, or Nginx with custom modules.
  • BFF (Backend-for-Frontend): Specific gateways for different clients (e.g., a Mobile Gateway and a Web Gateway) to optimize payloads.
  • Service Mesh Integration: Using gateways (like Istio Ingress) to manage "North-South" traffic while the mesh handles "East-West" traffic.

💡 Interview "Gotchas" & Tips

  • Global vs. Local Auth: Don't do full database-lookups for auth at the gateway. Validate the token signature and pass user context (like User-ID) in headers to downstream services.
  • Storage of State: A gateway should be stateless to scale horizontally. Use Redis if you need shared state for rate limiting.
  • Error Handling: Ensure the gateway returns standardized error codes (e.g., 429 for rate limiting, 503 for circuit breaking) so clients can react correctly.
  • BFF Pattern: Mention this if the requirements for mobile and web differ significantly (e.g., bandwidth constraints on mobile).

📐 Suggested Architecture Primitives

  • Load Balancer: Place an L4/L7 load balancer (like AWS ALB or Nginx) in front of the API Gateway for high availability.
  • Service Discovery: Integrate with Consul, Eureka, or Kubernetes DNS to dynamic route to changing service IPs.
  • Observability: Export logs and metrics to Prometheus, ELK, or Datadog for real-time monitoring.
  • Cache: Implement an edge cache (like Redis or Varnish) within the gateway for frequently accessed, non-user-specific data.
Canvas