Popular gateways (Kong, AWS API Gateway, Nginx) in Microservices - System Design Exercise

Design: API Gateway System for Microservices

Design the API gateway layer that manages traffic between clients and microservices. Exclude internal microservice design and database details.

Functional Requirements

FR1: Route client requests to appropriate microservices

FR2: Handle authentication and authorization

FR3: Provide rate limiting to prevent abuse

FR4: Enable request and response transformation

FR5: Support logging and monitoring of API calls

FR6: Allow easy addition or removal of microservices

FR7: Ensure high availability and low latency

Non-Functional Requirements

NFR1: Must handle 10,000 concurrent requests

NFR2: API response latency p99 under 200ms

NFR3: 99.9% uptime availability

NFR4: Support REST and WebSocket protocols

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

❓ Question 6

Key Components

API Gateway server (Kong, AWS API Gateway, or Nginx)

Authentication and authorization module

Rate limiting and throttling component

Load balancer

Service registry or discovery system

Logging and monitoring tools

Configuration management

Design Patterns

Reverse proxy pattern

Circuit breaker pattern

Token-based authentication

Rate limiting algorithms (token bucket, leaky bucket)

Blue-green deployment for gateway updates

Reference Architecture

API Gateway

↓

Auth Service

↓

Load Balancer

↓

Microservices Cluster

↓

Databases

Components

API Gateway

Kong / AWS API Gateway / Nginx

Entry point for all client requests, routes to microservices, handles protocol translation

Authentication Module

JWT, OAuth plugins or custom middleware

Verify client identity and permissions before forwarding requests

Rate Limiter

Built-in gateway plugins or external service

Limit number of requests per client to prevent abuse

Load Balancer

Nginx or cloud load balancer

Distribute incoming requests evenly across microservice instances

Service Registry

Consul, Eureka, or built-in discovery

Keep track of available microservice instances for routing

Logging and Monitoring

Prometheus, Grafana, ELK stack

Collect metrics and logs for observability and troubleshooting

Request Flow

1. Client sends request to API Gateway

2. API Gateway authenticates request using Authentication Module

3. API Gateway checks rate limits via Rate Limiter

4. If allowed, API Gateway routes request to Load Balancer

5. Load Balancer forwards request to appropriate microservice instance

6. Microservice processes request and sends response back

7. API Gateway logs request and response details

8. API Gateway returns response to client

Database Schema

Not applicable as this design focuses on API Gateway layer; microservices manage their own databases.

Scaling Discussion

Bottlenecks

API Gateway becoming a single point of failure under high load

Rate limiter performance degrading with many clients

Authentication module causing latency if external calls are slow

Load balancer unevenly distributing traffic

Logging system overwhelmed by high request volume

Solutions

Deploy multiple API Gateway instances behind a load balancer for high availability

Use distributed rate limiting with in-memory stores like Redis for speed

Cache authentication tokens and use asynchronous verification where possible

Implement health checks and smart load balancing algorithms

Use scalable logging pipelines with batching and sampling

Interview Tips

Time: 10 minutes for requirements and clarifications, 15 minutes for architecture and data flow, 10 minutes for scaling and trade-offs, 10 minutes for questions

Explain why API Gateway is critical for microservices communication

Discuss trade-offs between Kong, AWS API Gateway, and Nginx

Highlight importance of authentication and rate limiting

Describe how to ensure high availability and low latency

Mention monitoring and logging for operational excellence

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