Authentication at gateway level in Microservices - Scalability & System Analysis

Scalability Analysis - Authentication at gateway level

Growth Table: Authentication at Gateway Level

Users	Requests per Second (RPS)	Gateway Load	Auth Service Load	Latency Impact	Scaling Needs
100 users	~10 RPS	Low, single gateway instance	Low, single auth instance	Negligible	Basic setup, no scaling needed
10,000 users	~1,000 RPS	Moderate, gateway CPU & memory increase	Moderate, auth service CPU & DB queries increase	Small latency increase possible	Start load balancing gateways, caching tokens
1,000,000 users	~100,000 RPS	High, multiple gateway instances behind LB	High, auth DB and token validation bottleneck	Noticeable latency if no caching	Horizontal scaling, token caching, DB replicas
100,000,000 users	~10,000,000 RPS	Very high, global distributed gateways	Very high, sharded auth DB, distributed cache	Latency critical, must optimize	Global load balancing, CDN for static tokens, sharding, microservice partitioning

First Bottleneck

The authentication database and token validation service become the first bottleneck as user requests grow. This is because every request at the gateway requires token verification, which involves database lookups or cryptographic operations. The gateway itself can scale horizontally, but the auth service and its database can get overwhelmed by high QPS.

Scaling Solutions

• Horizontal Scaling: Add more gateway instances behind a load balancer to handle more concurrent connections.
• Token Caching: Cache validated tokens in a fast in-memory store (e.g., Redis) to reduce DB hits.
• Read Replicas: Use read replicas for the authentication database to spread read load.
• Stateless Tokens: Use JWT or similar tokens that can be validated without DB calls.
• Sharding: Partition the authentication data by user segments to reduce DB contention.
• Global Distribution: Deploy gateways and caches close to users to reduce latency.
• Rate Limiting: Protect the auth service from overload by limiting requests per user/IP.

Back-of-Envelope Cost Analysis

Assuming 1 million users generate 100,000 RPS:

• Each gateway server handles ~5,000 RPS → Need ~20 gateway servers.
• Auth DB handles ~10,000 QPS max → Need at least 10 read replicas or use stateless tokens.
• Token cache (Redis) handles ~100,000 ops/sec → Single Redis cluster can suffice.
• Network bandwidth: 100,000 RPS x 1 KB/request ≈ 100 MB/s (~800 Mbps), requires 1 Gbps network links.
• Storage: Auth DB stores user credentials and tokens, grows with user base; sharding helps manage size.

Interview Tip

Start by explaining the authentication flow at the gateway. Identify the bottleneck (auth DB and token validation). Discuss scaling the gateway horizontally first, then caching tokens to reduce DB load. Mention stateless tokens to avoid DB calls. Finally, talk about global distribution and rate limiting to handle very large scale.

Self Check

Your database handles 1000 QPS. Traffic grows 10x to 10,000 QPS. What do you do first?

Answer: Implement token caching or switch to stateless tokens (like JWT) to reduce DB queries. Also, add read replicas to distribute DB read load. This reduces pressure on the database before scaling hardware.

Key Result

Authentication at gateway level scales well initially by adding gateway instances, but the authentication database and token validation become bottlenecks at high traffic. Caching tokens and using stateless tokens are key to scaling beyond millions of users.

Practice

1. What is the main benefit of performing authentication at the gateway level in a microservices architecture?

easy

A. It slows down the request processing by adding extra steps.

B. It allows each microservice to handle its own authentication independently.

C. It eliminates the need for authorization in microservices.

D. It centralizes authentication, reducing repeated checks in each microservice.

Solution

1. Step 1: Understand the role of gateway authentication

   Authentication at the gateway means checking user identity once before requests reach microservices.

2. Step 2: Identify benefits of centralizing authentication

   This reduces repeated authentication logic inside each microservice, improving maintainability and security.

3. Final Answer:

   It centralizes authentication, reducing repeated checks in each microservice. -> Option D

4. Quick Check:

   Centralized authentication = It centralizes authentication, reducing repeated checks in each microservice. [OK]

Hint: Gateway authentication centralizes checks, avoiding repetition [OK]

Common Mistakes:

• Thinking each microservice should authenticate independently
• Confusing authentication with authorization
• Assuming gateway authentication slows down system

2. Which of the following is the correct way to implement authentication at the gateway level?

easy

A. The gateway validates user tokens and forwards requests with user info.

B. The gateway forwards requests without checking authentication.

C. Each microservice validates user tokens independently.

D. Microservices share a database to authenticate users directly.

Solution

1. Step 1: Identify gateway's role in token validation

   The gateway should validate user tokens to confirm identity before forwarding requests.

2. Step 2: Understand forwarding with user info

   After validation, the gateway forwards requests including user identity details for downstream services.

3. Final Answer:

   The gateway validates user tokens and forwards requests with user info. -> Option A

4. Quick Check:

   Gateway validates tokens = The gateway validates user tokens and forwards requests with user info. [OK]

Hint: Gateway validates tokens, then forwards requests with user info [OK]

Common Mistakes:

• Letting microservices validate tokens independently
• Not validating tokens at the gateway
• Using shared database for authentication in microservices

3. Consider this simplified request flow code snippet at the gateway:

function handleRequest(request) {
  const token = request.headers['Authorization'];
  if (!validateToken(token)) {
    return { status: 401, message: 'Unauthorized' };
  }
  return forwardRequest(request);
}

What will happen if validateToken always returns false?

medium

A. All requests will be forwarded to microservices.

B. Requests without tokens will be forwarded, others rejected.

C. All requests will be rejected with 401 Unauthorized.

D. Gateway will crash due to invalid token handling.

Solution

1. Step 1: Analyze the token validation condition

   If validateToken(token) returns false, the code returns 401 Unauthorized immediately.

2. Step 2: Determine effect on all requests

   Since it always returns false, no requests pass validation, so all are rejected with 401.

3. Final Answer:

   All requests will be rejected with 401 Unauthorized. -> Option C

4. Quick Check:

   Always false validation = 401 rejection [OK]

Hint: False validation means all requests rejected [OK]

Common Mistakes:

• Assuming requests are forwarded despite failed validation
• Thinking gateway crashes on invalid token
• Ignoring the immediate return on failed validation

4. A gateway is designed to authenticate requests but sometimes forwards unauthorized requests to microservices. What is the most likely cause?

medium

A. The gateway does not check the token before forwarding.

B. The gateway caches old valid tokens and skips validation.

C. The gateway uses synchronous token validation.

D. Microservices override the gateway authentication.

Solution

1. Step 1: Identify why unauthorized requests pass

   If the gateway caches tokens and skips validation, expired or revoked tokens may be accepted.

2. Step 2: Understand caching impact on authentication

   Cached tokens can cause stale validation results, allowing unauthorized requests through.

3. Final Answer:

   The gateway caches old valid tokens and skips validation. -> Option B

4. Quick Check:

   Token caching causes stale auth = The gateway caches old valid tokens and skips validation. [OK]

Hint: Stale token cache causes unauthorized forwarding [OK]

Common Mistakes:

• Assuming microservices override gateway auth
• Ignoring token caching effects
• Confusing synchronous validation with forwarding issues

5. You are designing a microservices system with authentication at the gateway level. To ensure high availability and avoid a single point of failure, which design approach is best?

hard

A. Deploy multiple gateway instances behind a load balancer with shared session storage.

B. Use a single gateway instance with a backup database for tokens.

C. Let each microservice authenticate independently to avoid gateway failure.

D. Disable authentication at the gateway and rely on microservices.

Solution

1. Step 1: Identify high availability needs for gateway

   Multiple gateway instances prevent downtime if one fails, improving reliability.

2. Step 2: Understand role of load balancer and shared session storage

   Load balancer distributes requests; shared session storage keeps authentication state consistent across gateways.

3. Final Answer:

   Deploy multiple gateway instances behind a load balancer with shared session storage. -> Option A

4. Quick Check:

   Multiple gateways + load balancer = high availability [OK]

Hint: Use multiple gateways with load balancer for reliability [OK]

Common Mistakes:

• Relying on single gateway instance only
• Ignoring session consistency across gateways
• Disabling gateway authentication entirely