Popular gateways (Kong, AWS API Gateway, Nginx) in Microservices - Deep Dive

Overview - Popular gateways (Kong, AWS API Gateway, Nginx)

What is it?

Popular gateways like Kong, AWS API Gateway, and Nginx are tools that manage and control how different parts of a software system talk to each other. They act as a middleman between users and backend services, handling requests, security, and traffic. These gateways help organize and protect microservices by routing requests, enforcing rules, and collecting data. Without them, managing many small services would be chaotic and insecure.

Why it matters

Without gateways, each microservice would need to handle security, routing, and traffic control on its own, making the system complex and error-prone. Gateways simplify communication, improve security, and help scale systems smoothly. They make sure users get the right data quickly and safely, which is crucial for apps we rely on daily like online shopping, banking, or social media.

Where it fits

Before learning about gateways, you should understand what microservices are and how services communicate over networks. After mastering gateways, you can explore advanced topics like service meshes, distributed tracing, and API management platforms.

Mental Model

Core Idea

A gateway is a smart traffic controller that directs, protects, and monitors requests between users and microservices.

Think of it like...

Imagine a busy train station where a station master directs trains to the correct tracks, checks tickets for security, and announces delays. The gateway plays the role of this station master for software requests.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│    Clients    │──────▶│    Gateway    │──────▶│ Microservices │
│ (Users/Apps)  │       │ (Kong, AWS,   │       │  (Services)   │
│               │       │  Nginx)       │       │               │
└───────────────┘       └───────────────┘       └───────────────┘

Build-Up - 7 Steps

1

Foundation

What is an API Gateway?

Concept: Introduces the basic role of an API gateway as a single entry point for multiple services.

An API gateway is a server that acts as a single point where all client requests arrive before reaching backend services. It routes requests to the correct service, handles security checks, and can modify requests or responses. This simplifies client interactions by hiding the complexity of many services behind one interface.

Result

You understand that an API gateway centralizes communication and simplifies client access to multiple services.

Understanding the gateway as a single entry point clarifies how it reduces complexity for both clients and services.

2

Foundation

Basic Functions of Gateways

Concept: Explains core functions like routing, security, and load balancing.

Gateways route requests to the right service based on the URL or other rules. They check if the request is allowed using authentication and authorization. They can balance load by distributing requests evenly to multiple service instances. They also collect data on requests for monitoring.

Result

You see how gateways improve security, reliability, and observability of microservices.

Knowing these basic functions shows why gateways are essential for managing many services efficiently.

3

Intermediate

Kong Gateway Overview

🤔Before reading on: do you think Kong is only a simple proxy or does it offer plugins and extensions? Commit to your answer.

Concept: Introduces Kong as an open-source, plugin-based API gateway.

Kong is an open-source gateway built on Nginx and designed for extensibility. It supports many plugins for authentication, rate limiting, logging, and more. Kong can run on-premises or in the cloud and supports both REST and gRPC protocols. It uses a database to store configuration and can scale horizontally.

Result

You learn Kong is flexible and customizable, suitable for complex microservice environments.

Understanding Kong's plugin system reveals how gateways can be tailored to specific needs without changing core code.

4

Intermediate

AWS API Gateway Features

🤔Before reading on: do you think AWS API Gateway only routes requests or also integrates with other AWS services? Commit to your answer.

Concept: Explains AWS API Gateway as a fully managed cloud service tightly integrated with AWS ecosystem.

AWS API Gateway is a managed service that handles all the heavy lifting of running a gateway. It supports REST, WebSocket, and HTTP APIs. It integrates with AWS Lambda for serverless backends and other AWS services like IAM for security. It automatically scales and provides built-in monitoring and caching.

Result

You understand AWS API Gateway simplifies gateway management by offloading infrastructure tasks to AWS.

Knowing AWS API Gateway's integration helps you see how cloud providers add value by combining services.

5

Intermediate

Nginx as a Gateway

🤔Before reading on: do you think Nginx is only a web server or can it act as a full API gateway? Commit to your answer.

Concept: Shows how Nginx, originally a web server, can be configured as a lightweight API gateway.

Nginx is a high-performance web server that can also route and proxy requests to backend services. With configuration, it can handle load balancing, SSL termination, and basic authentication. It lacks built-in API management features but is very fast and reliable. Many gateways like Kong build on Nginx.

Result

You see Nginx as a flexible base for building custom gateways or simple routing layers.

Understanding Nginx's role clarifies the difference between basic proxies and full-featured gateways.

6

Advanced

Scaling and High Availability

🤔Before reading on: do you think a single gateway instance can handle all traffic in large systems? Commit to your answer.

Concept: Discusses how gateways scale and stay available under heavy load.

Gateways scale by running multiple instances behind a load balancer. They share configuration via databases or cloud services. High availability means if one instance fails, others continue serving requests. Some gateways support clustering and distributed caches to keep state consistent. Proper scaling avoids bottlenecks and downtime.

Result

You understand the importance of running gateways in clusters for reliability and performance.

Knowing how gateways scale prevents design mistakes that cause outages or slowdowns.

7

Expert

Extending Gateways with Plugins and Custom Logic

🤔Before reading on: do you think all gateways allow deep customization or only some? Commit to your answer.

Concept: Explores how gateways like Kong allow adding custom plugins to extend functionality.

Kong supports Lua-based plugins that can modify requests, add new security checks, or integrate with external systems. AWS API Gateway allows custom authorizers and request transformations using AWS Lambda. Nginx can be extended with modules or scripts. This flexibility lets teams adapt gateways to unique business needs without changing backend services.

Result

You see how extensibility makes gateways powerful tools beyond simple routing.

Understanding plugin systems reveals how gateways evolve with changing requirements without major rewrites.

Under the Hood

Gateways receive client requests and inspect them to decide where to send them. They use routing rules based on URLs, headers, or methods. They enforce security by checking tokens or credentials before forwarding. Internally, they maintain connection pools to backend services for efficiency. Some store configuration in databases or distributed caches to synchronize multiple instances. Plugins or modules run code during request processing to add features.

Why designed this way?

Gateways were designed to centralize common tasks like security and routing to avoid duplication in each service. Using a proxy model allows them to sit between clients and services without changing either. Extensibility via plugins was added to adapt to diverse needs without bloating the core. Cloud providers built managed gateways to reduce operational overhead for users.

┌───────────────┐
│   Client Req  │
└──────┬────────┘
       │
┌──────▼───────┐
│   Gateway    │
│ ┌─────────┐ │
│ │ Routing │ │
│ ├─────────┤ │
│ │Security │ │
│ ├─────────┤ │
│ │ Plugins │ │
│ └─────────┘ │
└──────┬──────┘
       │
┌──────▼───────┐
│ Backend Svc  │
└──────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do you think an API gateway replaces all backend services? Commit yes or no.

Common Belief: An API gateway is a backend service that does all the work instead of microservices.

Reality: An API gateway only manages and routes requests; it does not replace the business logic inside microservices.

Why it matters: Thinking the gateway replaces services leads to overloading it with logic, causing performance and maintenance problems.

Quick: Do you think Nginx automatically provides API management features? Commit yes or no.

Common Belief: Nginx is a full API gateway with built-in authentication and rate limiting.

Reality: Nginx is primarily a web server and reverse proxy; it requires extra configuration or modules to add API gateway features.

Why it matters: Assuming Nginx alone is enough can cause missing critical security or monitoring features.

Quick: Do you think AWS API Gateway requires manual scaling? Commit yes or no.

Common Belief: You must manually scale AWS API Gateway instances to handle more traffic.

Reality: AWS API Gateway is fully managed and automatically scales to meet demand.

Why it matters: Misunderstanding this leads to unnecessary operational work and potential misconfiguration.

Quick: Do you think all gateways support the same protocols? Commit yes or no.

Common Belief: All API gateways support every protocol like REST, gRPC, and WebSocket equally.

Reality: Different gateways specialize in different protocols; some may lack support or have limited features for certain types.

Why it matters: Choosing a gateway without protocol support can block needed functionality or cause complex workarounds.

Expert Zone

1

Some gateways cache authentication tokens to reduce latency but must carefully handle token expiration to avoid security risks.

2

Distributed configuration management in gateways can cause subtle consistency issues if not designed with eventual consistency in mind.

3

Plugin execution order matters; poorly ordered plugins can cause unexpected behavior or performance bottlenecks.

When NOT to use

Gateways are not ideal for extremely low-latency systems where even small delays matter; direct service-to-service calls or service meshes may be better. Also, for very simple systems with few services, a gateway might add unnecessary complexity.

Production Patterns

In production, teams often deploy gateways in clusters behind load balancers with health checks. They use plugins for authentication, rate limiting, and logging. Cloud gateways integrate with monitoring and alerting tools. Hybrid setups combine managed gateways with on-premises ones for compliance.

Connections

Service Mesh

Builds-on and complements

Understanding gateways helps grasp service meshes, which manage service-to-service communication inside the system, while gateways handle external traffic.

Load Balancing

Shares core principles

Gateways often include load balancing, so knowing load balancing concepts clarifies how gateways distribute traffic efficiently.

Airport Control Tower

Similar role in different domain

Just like an airport control tower directs planes safely and efficiently, gateways direct software requests, showing how control and routing are universal challenges.

Common Pitfalls

#1 Overloading the gateway with business logic.

Wrong approach:

Adding complex data processing or business rules inside gateway plugins instead of backend services.

Correct approach:

Keep gateways focused on routing, security, and monitoring; implement business logic inside microservices.

Root cause:

Misunderstanding the gateway's role leads to mixing concerns and harder maintenance.

#2 Not planning for gateway scaling and availability.

Wrong approach:

Deploying a single gateway instance without redundancy or load balancing.

Correct approach:

Run multiple gateway instances behind a load balancer with health checks and shared configuration.

Root cause:

Underestimating traffic volume and failure risks causes outages.

#3 Assuming all gateways support all protocols out of the box.

Wrong approach:

Choosing a gateway without verifying support for required protocols like gRPC or WebSocket.

Correct approach:

Evaluate gateway protocol support carefully and test with your services before adoption.

Root cause:

Lack of protocol knowledge leads to integration failures.

Key Takeaways

API gateways act as a central point that manages, secures, and routes requests between clients and microservices.

Popular gateways like Kong, AWS API Gateway, and Nginx differ in features, extensibility, and management style but share core responsibilities.

Gateways simplify complex microservice communication by handling common tasks like authentication, rate limiting, and load balancing.

Proper scaling and high availability of gateways are critical to avoid bottlenecks and downtime in production systems.

Extensibility through plugins or integrations allows gateways to adapt to evolving business needs without changing backend services.

Practice

1. Which of the following is a primary role of API gateways like Kong, AWS API Gateway, or Nginx in microservices?

easy

A. Control and protect communication between services

B. Store large amounts of data

C. Run backend business logic

D. Replace databases in microservices

Solution

1. Step 1: Understand the role of API gateways

   API gateways act as a control point for requests between clients and microservices, managing traffic and security.

2. Step 2: Compare options with gateway functions

   Storing data, running business logic, or replacing databases are not typical gateway roles.

3. Final Answer:

   Control and protect communication between services -> Option A

4. Quick Check:

   Gateway role = Control communication [OK]

Hint: Gateways manage traffic and security, not data storage [OK]

Common Mistakes:

• Confusing gateways with databases
• Thinking gateways run business logic
• Assuming gateways store data

2. Which syntax correctly defines a route in Kong's configuration to forward requests to a service?

easy

A. routes:\n - name example-route\n path: '/example'\n service: example-service

B. routes:\n - name: example-route\n paths: ['/example']\n service: example-service

C. routes:\n - name: example-route\n paths: '/example'\n service: example-service

D. routes:\n - example-route:\n paths: ['/example']\n service: example-service

Solution

1. Step 1: Review Kong route syntax

   Kong routes use a list with keys: name, paths (as a list), and service.

2. Step 2: Identify correct YAML structure

   routes:\n - name: example-route\n paths: ['/example']\n service: example-service correctly uses a list with dash, keys with colons, and paths as a list.

3. Final Answer:

   routes:\n - name: example-route\n paths: ['/example']\n service: example-service -> Option B

4. Quick Check:

   Kong route syntax = routes:\n - name: example-route\n paths: ['/example']\n service: example-service [OK]

Hint: YAML lists need dashes and keys with colons [OK]

Common Mistakes:

• Missing colon after keys
• Using string instead of list for paths
• Incorrect indentation or dash placement

3. Given this Nginx configuration snippet, what happens when a client requests /api/users?

location /api/ {
  proxy_pass http://backend-service/;
}

medium

A. The request is forwarded to http://backend-service/users

B. The request returns a 404 error

C. The request is blocked by Nginx

D. The request is forwarded to http://backend-service/api/users

Solution

1. Step 1: Understand Nginx proxy_pass behavior with trailing slash

   When proxy_pass URL ends with a slash, Nginx replaces the matching location prefix with the proxy URL path.

2. Step 2: Apply to given example

   Location prefix is /api/, proxy_pass is http://backend-service/, so /api/ is replaced by /, forwarding /users to backend-service.

3. Final Answer:

   The request is forwarded to http://backend-service/users -> Option A

4. Quick Check:

   Trailing slash in proxy_pass removes location prefix [OK]

Hint: Trailing slash in proxy_pass removes location prefix [OK]

Common Mistakes:

• Assuming full path is appended
• Confusing proxy_pass with or without trailing slash
• Thinking request is blocked or 404

4. You configured AWS API Gateway with a resource path /items and a GET method, but requests to /items return 403 Forbidden. What is the most likely cause?

medium

A. The backend service URL is incorrect

B. The API Gateway does not support GET methods

C. The GET method is not deployed or enabled in the stage

D. The client IP is blocked by AWS firewall

Solution

1. Step 1: Check AWS API Gateway method deployment

   Methods must be deployed and enabled in the stage to accept requests.

2. Step 2: Understand 403 Forbidden meaning in API Gateway

   403 often means method exists but is not authorized or deployed, not backend URL or IP block.

3. Final Answer:

   The GET method is not deployed or enabled in the stage -> Option C

4. Quick Check:

   403 = method not deployed/enabled [OK]

Hint: Deploy methods in stage to avoid 403 errors [OK]

Common Mistakes:

• Assuming backend URL causes 403
• Thinking API Gateway disallows GET
• Blaming client IP blocking without evidence

5. You want to use Kong to route requests to two microservices: serviceA at /serviceA and serviceB at /serviceB. Which configuration approach ensures correct routing and avoids path conflicts?

hard

A. Create two routes with the same path ['/service'] for both services

B. Create one route with path ['/'] forwarding to both services

C. Use a single route with no path and rely on backend to differentiate

D. Create two routes with paths ['/serviceA'] and ['/serviceB'], each linked to their respective services

Solution

1. Step 1: Understand routing by path in Kong

   Kong routes requests based on path prefixes to the correct service.

2. Step 2: Avoid path conflicts by using distinct paths

   Separate paths like '/serviceA' and '/serviceB' ensure requests go to the right service without overlap.

3. Final Answer:

   Create two routes with paths ['/serviceA'] and ['/serviceB'], each linked to their respective services -> Option D

4. Quick Check:

   Distinct paths = correct routing [OK]

Hint: Use unique paths per service to avoid conflicts [OK]

Common Mistakes:

• Using same path for multiple services
• Relying on backend to route without gateway paths
• Using root path for all services