Gateway as Single Entry Point - What Is An Api Gateway | OneNoughtOne

System Design (HLD)What Is an API Gateway?

What Is an API Gateway?

LevelIntermediate

Duration60 mins

TopicWhat Is an API Gateway?

1 / 4

Gateway as Single Entry Point

1

The Complexity of Modern Distributed Systems

Consider a typical modern application: a mobile app that allows users to browse products, add items to a cart, process payments, track orders, and receive notifications. Behind this seemingly simple interface lies an intricate web of services—each responsible for a specific domain: Product Catalog Service, Inventory Service, Cart Service, Payment Service, Order Service, Notification Service, User Service, Search Service, and potentially dozens more.

Now imagine a mobile client trying to render a single product detail page. It needs product information, inventory status, user reviews, pricing, recommendations, and availability in nearby stores. Without a unified access layer, the client must:

Know the network locations of 6+ different services
Make 6+ separate HTTP requests over a mobile network
Handle authentication for each service individually
Manage failures, timeouts, and retries for each connection
Aggregate and correlate the responses client-side

This approach is fundamentally untenable at scale. It creates tight coupling between clients and services, exposes internal architecture to the outside world, overwhelms mobile networks with chattiness, and makes coordinated changes across services nearly impossible.

What You Will Learn

By the end of this page, you will understand why the API Gateway pattern exists, how it solves the fundamental problems of client-to-microservices communication, and the architectural principles that make it the single entry point for all external traffic in distributed systems.

1

The Genesis of API Gateways

The API Gateway pattern emerged as a direct response to the challenges of microservices architecture. In the monolithic era, a single application served all client requests—routing, authentication, and response formatting happened within one process boundary. The transition to microservices distributed these responsibilities across dozens or hundreds of independent services, creating a fundamental problem: how do clients interact with a system that no longer has a single address?

The Façade Pattern at Scale

An API Gateway is, at its core, an application of the Façade design pattern to distributed systems. Just as a façade simplifies a complex subsystem by providing a unified interface, an API Gateway presents a coherent, simplified API to clients while hiding the internal complexity of the service mesh behind it.

However, the API Gateway transcends the traditional façade in several critical ways:

Façade Pattern vs. API Gateway
Aspect	Traditional Façade	API Gateway
Scope	In-process, single application	Network-level, distributed systems
Protocol	Method calls within same runtime	HTTP, gRPC, WebSocket, GraphQL
Concerns	Interface simplification	Cross-cutting concerns: auth, rate limiting, observability
Scale	Single deployment unit	Gateway for entire organization/product
Evolution	Compile-time changes	Dynamic routing, canary deployments, A/B testing
Failure Modes	Exception handling	Timeouts, circuit breakers, fallbacks

Historical Context: From Hardware to Software

The concept of a gateway predates the current microservices era. Network engineers have long used gateways to bridge different network segments and protocols. Early API management evolved from Enterprise Service Buses (ESBs) in the SOA (Service-Oriented Architecture) era of the 2000s.

However, ESBs became notorious for becoming monolithic chokepoints themselves—embedding business logic, transformation rules, and orchestration that coupled services together. The modern API Gateway learned from these mistakes:

ESBs were smart pipes with dumb endpoints
API Gateways are dumb pipes with smart endpoints

The modern philosophy pushes business logic to services while the gateway handles infrastructure concerns: routing, security, and observability. This separation of concerns is fundamental to understanding what an API Gateway should—and crucially, should not—do.

Anti-Pattern Alert: The Intelligent Gateway

One of the most common architectural mistakes is placing business logic in the API Gateway. When your gateway starts making business decisions, aggregating data with custom logic, or transforming payloads beyond simple protocol translation, you've recreated the ESB monolith. The gateway should route and protect—never decide or compute.

2

Anatomy of the Single Entry Point

When we say the API Gateway is a "single entry point," we're making a profound architectural statement. Let's dissect exactly what this means and why it matters.

The Boundary Definition

The API Gateway defines the boundary between the external world and the internal system. This boundary has critical properties:

Boundary Properties

•Network Isolation — Internal services live in private networks (VPCs) with no public IP addresses. Only the gateway has external network exposure, dramatically reducing the attack surface.
•Protocol Translation — External clients speak HTTP/1.1 or HTTP/2 over TLS; internal services might communicate via gRPC, internal protocols, or message queues. The gateway bridges these worlds.
•Identity Context — External requests carry opaque tokens; internal requests carry verified, enriched identity information (user ID, permissions, tenant ID). The gateway performs this translation.
•Trust Boundary — Everything outside the gateway is untrusted. Everything behind it operates within a zone of implicit trust (validated by the gateway).
•Versioning Abstraction — Clients see stable, versioned APIs; internally, services evolve independently. The gateway maps external versions to internal implementations.

┌─────────────────────────────────────────────────────────────────────────────────┐
│                              EXTERNAL WORLD (Untrusted)                         │
│  ┌──────────┐   ┌──────────┐   ┌──────────┐   ┌────────────────┐                │
│  │  Mobile  │   │   Web    │   │  3rd Party│  │   IoT Device   │                │
│  │   App    │   │  Browser │   │   Client │   │                │                │
│  └────┬─────┘   └────┬─────┘   └────┬─────┘   └───────┬────────┘                │
│       │              │              │                 │                          │
│       └──────────────┴──────────────┴─────────────────┘                          │
│                                     │                                            │
│                          HTTPS / WSS / GraphQL                                   │
│                                     ▼                                            │
├─────────────────────────────────────────────────────────────────────────────────┤
│                           ╔═══════════════════════╗                              │
│                           ║     API GATEWAY       ║                              │
│                           ║  ─────────────────    ║                              │
│                           ║  • TLS Termination    ║                              │
│                           ║  • Authentication     ║                              │
│                           ║  • Rate Limiting      ║                              │
│                           ║  • Request Routing    ║                              │
│                           ║  • Protocol Translation║                             │
│                           ║  • Observability      ║                              │
│                           ╚═══════════╦═══════════╝                              │
│                                       │                                          │
├─────────────────────────────────────────────────────────────────────────────────┤
│                              INTERNAL WORLD (Trusted)                            │
│                                       │                                          │
│                    ┌──────────────────┼──────────────────┐                       │
│                    │                  │                  │                       │
│                    ▼                  ▼                  ▼                       │
│             ┌──────────┐       ┌──────────┐       ┌──────────┐                   │
│             │  Product │       │   User   │       │   Order  │                   │
│             │  Service │       │  Service │       │  Service │                   │
│             └──────────┘       └──────────┘       └──────────┘                   │
│                    │                  │                  │                       │
│                    └──────────────────┼──────────────────┘                       │
│                                       ▼                                          │
│                              ┌───────────────┐                                   │
│                              │   Databases   │                                   │
│                              │   & Caches    │                                   │
│                              └───────────────┘                                   │
└─────────────────────────────────────────────────────────────────────────────────┘

What "Single" Really Means

The term "single entry point" deserves careful examination. It does not mean:

❌ One physical server handling all traffic
❌ One IP address for the entire system
❌ A single point of failure

It does mean:

✅ One logical point of entry for a given client type or API product
✅ A unified abstraction that can scale horizontally behind load balancers
✅ A single set of policies, configurations, and contracts for external clients

In practice, production API Gateways run as highly available clusters behind global load balancers, potentially distributed across multiple regions. The "single entry point" is a logical abstraction—a consistent interface that clients interact with, regardless of the physical infrastructure behind it.

Multiple Gateways for Different Audiences

Large organizations often deploy multiple API Gateways for different purposes: one for mobile apps, one for web applications, one for third-party developers (public API), and one for internal service-to-service communication. Each is a 'single entry point' for its specific audience.

3

The Problems Solved by a Single Entry Point

Understanding why the API Gateway pattern exists requires understanding the problems that arise without it. Let's examine the critical challenges that a unified entry point solves.

Without API Gateway

•Client Complexity — Clients must discover and track locations of many services
•N+1 Network Calls — One page load triggers requests to multiple services
•Duplicated Auth Logic — Every service implements authentication independently
•No Central Rate Limiting — Abuse protection scattered across services
•Observability Gaps — No unified view of request patterns
•Tight Coupling — Client changes required when services refactor
•Security Exposure — Every service requires public network exposure
•Protocol Fragmentation — Clients must speak multiple protocols

With API Gateway

•Unified Discovery — Clients know one address; gateway routes internally
•Request Aggregation — Gateway can compose responses from multiple services
•Centralized Auth — Single point for token validation and identity propagation
•Unified Rate Limiting — Consistent throttling policies across all APIs
•Complete Observability — All traffic flows through instrumented gateway
•Decoupled Evolution — Services change freely behind stable gateway APIs
•Reduced Attack Surface — Only gateway exposed; services in private network
•Protocol Normalization — External HTTP → internal gRPC, etc.

Deep Dive: The N+1 Problem in Client-Service Communication

Consider rendering a user's dashboard that displays:

User profile information
Recent orders (with product details)
Personalized recommendations
Notification count
Account balance

Without a gateway, the mobile client makes:

GET /users/123                          → User Service
GET /users/123/orders?limit=5           → Order Service  
GET /products/456,789,101               → Product Service (for order items)
GET /recommendations/users/123           → Recommendation Service
GET /notifications/users/123/count       → Notification Service
GET /payments/users/123/balance          → Payment Service

That's 6 sequential HTTP requests over a potentially unreliable mobile network. Each request has:

DNS resolution latency
TCP connection establishment (or reuse)
TLS handshake overhead
Request/response round-trip time
Potential retry on failure

Over a 100ms mobile latency, this dashboard takes 600ms minimum—often much longer with request queuing, retries, and error handling.

With an API Gateway, the client makes a single request:

GET /gateway/dashboard/users/123         → API Gateway

The gateway, operating within the low-latency internal network (sub-millisecond), parallelizes requests to backend services and aggregates the response. Total client latency: ~120ms (one round trip + gateway processing).

Aggregation: Use with Caution

While API Gateways can aggregate responses, this capability should be used sparingly. Complex aggregation logic in the gateway tends toward the anti-pattern of an 'intelligent gateway.' For sophisticated aggregation, consider the Backend-for-Frontend (BFF) pattern—a lightweight service that aggregates and transforms data for a specific client type.

4

Clients of the Gateway: Who Consumes the Entry Point?

An API Gateway serves multiple types of clients, each with distinct characteristics, requirements, and constraints. Understanding these client types informs gateway design decisions.

Client Types and Their Characteristics
Client Type	Network Characteristics	Update Frequency	Security Model	Key Concerns
Mobile Native (iOS/Android)	High latency, unreliable, bandwidth-constrained	Infrequent (app store)	OAuth tokens, certificate pinning	Payload size, offline support, backward compatibility
Single-Page Web Apps (SPA)	Variable latency, CORS requirements	Instant (browser refresh)	Session cookies, JWTs	Authentication flows, CORS, caching
Server-Side Web (SSR)	Low latency, reliable, internal	Deployment cycles	Service credentials, mTLS	Response time, error handling
Third-Party Developers	Unknown network, untrusted code	Uncontrolled	API keys, OAuth scopes	Rate limiting, documentation, versioning
IoT Devices	Extremely constrained, intermittent	Firmware updates (rare)	X.509 certificates, pre-shared keys	Payload efficiency (MQTT, CoAP), connection handling
Internal Services	Low latency, reliable, private network	Continuous deployment	mTLS, service mesh identity	Service discovery, circuit breaking
Partner Integrations	B2B connections, VPN possible	Contractual SLAs	Mutual TLS, IP allowlisting	Compliance, audit logging, SLA enforcement

Client-Specific Gateway Considerations

Mobile Clients demand special attention. They operate over cellular networks where:

Latency varies from 50ms to 500ms+ within seconds
Connections drop during transit (elevators, tunnels, handoffs)
Battery consumption is critical (connection establishment is expensive)
Bandwidth may be metered and throttled

This reality influences gateway design:

// Gateway configuration optimized for mobile clients
const mobileGatewayConfig = {
  // Aggressive compression for bandwidth-constrained clients
  compression: {
    enabled: true,
    minSize: 256,  // Compress responses over 256 bytes
    algorithm: 'gzip',
  },
  
  // Longer timeouts to accommodate high-latency networks
  timeout: {
    connect: 10000,   // 10s connect timeout
    request: 30000,   // 30s request timeout
  },
  
  // Keep connections alive to avoid TCP/TLS overhead
  keepAlive: {
    enabled: true,
    timeout: 120000,  // 2 minutes
  },
  
  // Support for resumable uploads
  chunkedUpload: {
    enabled: true,
    maxChunkSize: '1MB',
  },
  
  // Aggressive response caching
  cache: {
    default: 'private, max-age=60',
    // ETags for conditional requests
    etag: true,
  },
};

Third-Party Developer Clients introduce unique challenges:

You don't control the code — Developers may implement poorly: not handling errors, ignoring rate limits, caching incorrectly
You can't force updates — Once an API version is published, assume some developer will call it forever (or until you sunset it with warnings)
Abuse is inevitable — Whether malicious or accidental, third parties will stress your systems in unexpected ways
Documentation is the product — For external APIs, the gateway's API contract is the product

These realities drive stricter gateway policies for public APIs:

// Gateway configuration for public/external API
const publicApiGatewayConfig = {
  // Strict rate limiting (per API key)
  rateLimit: {
    default: 100,       // 100 requests per minute
    burst: 20,          // Allow bursts of 20
    headerPrefix: 'X-RateLimit',  // Return limit headers
  },
  
  // Mandatory authentication
  authentication: {
    required: true,
    methods: ['apiKey', 'oauth2'],
    invalidKeyResponse: {
      status: 401,
      body: { error: 'invalid_api_key', docs: 'https://api.example.com/docs/auth' },
    },
  },
  
  // Request validation
  validation: {
    strictMode: true,   // Reject unknown fields
    maxBodySize: '1MB', // Protect against payload attacks
  },
  
  // Audit logging for compliance
  logging: {
    level: 'detailed',
    includeRequestBody: true,
    includeResponseBody: false,  // Privacy
    retention: '90d',
  },
};

The Gateway Per-Client-Type Pattern

Organizations with diverse client types often deploy separate gateway instances (or configurations) for each client category. A mobile gateway might prioritize response compression and aggressive caching; a public API gateway emphasizes rate limiting and documentation; an internal gateway focuses on low latency and mTLS. Same gateway technology, different configurations and policies.

5

Architectural Principles of the Single Entry Point

Designing an API Gateway as the single entry point requires adherence to several architectural principles that ensure the gateway remains an asset rather than a liability.

Core Architectural Principles

•Statelessness — The gateway must not maintain session state between requests. Any gateway instance should be able to handle any request. State belongs in backend services or external stores (Redis, databases).
•Horizontal Scalability — Traffic scales by adding gateway instances, not by scaling up individual servers. The gateway is a pass-through layer that scales linearly with load.
•Failure Isolation — A failure in one backend service must not bring down the gateway or affect requests to other services. The gateway implements bulkheads, timeouts, and circuit breakers.
•Configuration-Driven Behavior — Routing rules, rate limits, and policies should be configurable without code changes or redeployments. Infrastructure-as-code principles apply.
•Observability by Default — Every request through the gateway generates traces, metrics, and logs. The gateway is the ideal vantage point for monitoring the entire system's health.
•Security as Core Function — Authentication, authorization, and threat detection are primary responsibilities, not afterthoughts. The gateway is the security perimeter.
•Low Latency Overhead — The gateway adds a network hop; it must minimize the latency cost of that hop. Efficient request processing is paramount.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
// ❌ ANTI-PATTERN: Stateful Gateway
class StatefulGateway {
  // Gateway maintains session state - BAD!
  private sessions: Map<string, UserSession> = new Map();
  
  async handleRequest(req: Request): Promise<Response> {
    const sessionId = req.cookies.get('sid');
    
    // Gateway is tied to specific sessions
    // If this instance dies, sessions are lost
    // Cannot scale horizontally without sticky sessions
    const session = this.sessions.get(sessionId);
    
    if (!session) {
      return new Response('Unauthorized', { status: 401 });
    }
    
    return this.routeToBackend(req, session);
  }
}
 
// ✅ CORRECT: Stateless Gateway Design
class StatelessGateway {
  constructor(
    private tokenValidator: JWTValidator,    // Validates tokens without state
    private rateLimiter: DistributedRateLimiter,  // State in Redis, not gateway
    private serviceRouter: ConfigurableRouter,   // Config from external source
  ) {}
  
  async handleRequest(req: Request): Promise<Response> {
    // Extract and validate token - no local state needed
    const token = req.headers.get('Authorization')?.replace('Bearer ', '');
    
    // Token is self-contained (JWT) - validates without database lookup
    // Or: quick lookup in distributed cache (Redis)
    const identity = await this.tokenValidator.validate(token);
    
    if (!identity) {
      return new Response('Unauthorized', { status: 401 });
    }
    
    // Check rate limits using distributed state (Redis)
    const allowed = await this.rateLimiter.checkLimit(identity.userId);
    
    if (!allowed) {
      return new Response('Rate Limited', { 
        status: 429,
        headers: { 'Retry-After': '60' },
      });
    }
    
    // Route based on configuration - any instance routes the same way
    const backend = this.serviceRouter.route(req.url);
    
    // Enrich request with validated identity
    const enrichedReq = this.enrichRequest(req, identity);
    
    return this.proxy(enrichedReq, backend);
  }
  
  private enrichRequest(req: Request, identity: Identity): Request {
    // Add internal headers that backend services trust
    return new Request(req.url, {
      ...req,
      headers: {
        ...Object.fromEntries(req.headers),
        'X-User-Id': identity.userId,
        'X-User-Roles': identity.roles.join(','),
        'X-Tenant-Id': identity.tenantId,
        'X-Request-Id': crypto.randomUUID(),
      },
    });
  }
}

The Statelessness Imperative

Any deviation from statelessness creates operational nightmares. Sticky sessions prevent load balancing. Local caches cause inconsistency. In-memory rate limiters fail across instances. If your gateway 'remembers' anything, ensure that memory is in an external distributed store (Redis, memcached) accessible to all gateway instances.

6

Real-World Single Entry Point Topologies

The conceptual "single entry point" translates to various physical topologies in production environments. Understanding these patterns helps you design for availability, performance, and operational requirements.

Topology 1: Single Region, Multi-AZ Deployment

The most common starting topology for organizations:

                        ┌─────────────────────────────────────┐
                        │            Route 53 (DNS)           │
                        │         api.example.com             │
                        └─────────────────┬───────────────────┘
                                          │
                        ┌─────────────────▼───────────────────┐
                        │     Application Load Balancer       │
                        │         (Cross-AZ, Health Checks)   │
                        └────────┬────────────────────────────┘
                                 │
            ┌────────────────────┼────────────────────┐
            │                    │                    │
    ┌───────▼───────┐    ┌───────▼───────┐    ┌───────▼───────┐
    │   Gateway     │    │   Gateway     │    │   Gateway     │
    │   Instance    │    │   Instance    │    │   Instance    │
    │   (AZ-1a)     │    │   (AZ-1b)     │    │   (AZ-1c)     │
    └───────────────┘    └───────────────┘    └───────────────┘

Characteristics:

DNS resolves to a single ALB
ALB distributes traffic across gateway instances in multiple Availability Zones
Gateway instances are identical, stateless, auto-scaled
Failure of one AZ doesn't impact service
Single region means higher latency for geographically distant clients

Topology 2: Multi-Region with Global Load Balancing

For global applications requiring low latency worldwide:

                    ┌───────────────────────────────────────────┐
                    │       Global DNS / Anycast / GeoDNS       │
                    │           api.example.com                 │
                    └───────────────────┬───────────────────────┘
                                        │
        ┌───────────────────────────────┼───────────────────────────────┐
        │                               │                               │
        ▼                               ▼                               ▼
┌───────────────┐               ┌───────────────┐               ┌───────────────┐
│   US-East-1   │               │   EU-West-1   │               │   AP-South-1  │
│   Gateway     │               │   Gateway     │               │   Gateway     │
│   Cluster     │               │   Cluster     │               │   Cluster     │
└───────┬───────┘               └───────┬───────┘               └───────┬───────┘
        │                               │                               │
        ▼                               ▼                               ▼
┌───────────────┐               ┌───────────────┐               ┌───────────────┐
│  US Services  │               │  EU Services  │               │  APAC Services│
│  (Primary)    │               │  (Replica)    │               │  (Replica)    │
└───────────────┘               └───────────────┘               └───────────────┘

Characteristics:

Clients connect to nearest regional gateway (typically <50ms latency)
Each region has its own gateway cluster and service deployments
Data replication between regions (async, eventual consistency)
Regional failures handled by DNS failover
Complex but essential for global user bases

Topology 3: Edge Deployment with CDN Integration

For maximum performance and DDoS protection:

                    ┌─────────────────────────────────────────────┐
                    │              CDN Edge Network               │
                    │  (Cloudflare, CloudFront, Akamai, Fastly)   │
                    │                                             │
                    │   ┌─────────────────────────────────────┐   │
                    │   │  Edge Functions / Workers           │   │
                    │   │  - Static content serving           │   │
                    │   │  - DDoS mitigation                  │   │
                    │   │  - Geographic routing               │   │
                    │   │  - Request validation               │   │
                    │   │  - JWT validation (edge)            │   │
                    │   └───────────────────┬─────────────────┘   │
                    └───────────────────────┼─────────────────────┘
                                            │ (Only dynamic requests 
                                            │  reach origin)
                                            ▼
                    ┌─────────────────────────────────────────────┐
                    │              Origin API Gateway             │
                    │         (Your Infrastructure)               │
                    └───────────────────────┬─────────────────────┘
                                            │
                                            ▼
                    ┌─────────────────────────────────────────────┐
                    │              Backend Services               │
                    └─────────────────────────────────────────────┘

Characteristics:

CDN handles caching, DDoS protection, TLS termination at edge
Only cache misses reach origin gateway (significant load reduction)
Edge functions can handle authentication, rate limiting, routing at edge
Two-tier gateway: edge (CDN) + origin (your gateway)
Best performance and resilience, but added complexity and cost

Choosing a Topology

Start simple (Topology 1) and evolve as requirements demand. Multi-region (Topology 2) becomes necessary when user base is global and sub-100ms latency matters. Edge deployment (Topology 3) adds value for static-heavy workloads, DDoS-prone environments, or when edge computing capabilities are needed.

7

Summary: The Gateway as Single Entry Point

We've explored the foundational concept of the API Gateway as the single entry point for distributed systems. Let's consolidate the essential insights:

Key Takeaways

•The Gateway is a Distributed Façade — It provides a simplified, unified interface to a complex mesh of backend services, hiding internal architecture from clients.
•Single Entry Point is Logical, Not Physical — The 'single' entry point is a consistent abstraction; behind it are horizontally scaled, highly available clusters.
•The Gateway Defines the Trust Boundary — Everything outside is untrusted and validated; everything inside operates within a zone of verified identity.
•Different Clients Need Different Gateways — Mobile, web, third-party, and internal clients have different requirements; design gateway configurations (or separate gateways) accordingly.
•Statelessness is Non-Negotiable — Any state the gateway needs must live in external, distributed stores. Gateway instances must be perfectly interchangeable.
•Keep the Gateway 'Dumb' — Route, protect, observe. Never compute, decide, or embed business logic. Smart endpoints, dumb pipes.
•Topology Evolves with Scale — Start with single-region multi-AZ; grow to multi-region or edge deployment as global scale demands.

What's Next:

With a solid understanding of what the API Gateway is and why it serves as the single entry point, we'll next explore the specific responsibilities of an API Gateway—the essential functions it performs as requests flow through it, from authentication and authorization to rate limiting, request transformation, and observability.

Page Complete

You now understand the fundamental role of an API Gateway as the single entry point for distributed systems. You've learned why this pattern exists, what problems it solves, how different clients consume it, and the architectural principles that govern its design. Next, we'll dive deep into the specific responsibilities that make the gateway an indispensable component of modern architectures.