JWT token propagation in Microservices - Scalability & System Analysis

Scalability Analysis - JWT token propagation

Growth Table: JWT Token Propagation at Different Scales

Users	Requests per Second (RPS)	Token Size & Overhead	Network Impact	Service Load
100 users	~50 RPS	Small (1-2 KB)	Minimal	Low CPU and memory usage
10,000 users	~5,000 RPS	Small (1-2 KB)	Noticeable increase in bandwidth	Moderate CPU for token verification
1,000,000 users	~500,000 RPS	Small (1-2 KB)	High bandwidth usage, network latency may increase	High CPU usage for token verification; potential bottleneck
100,000,000 users	~50,000,000 RPS	Small (1-2 KB)	Extremely high bandwidth; network saturation risk	Token verification becomes major CPU bottleneck; scaling challenges

First Bottleneck

The first bottleneck in JWT token propagation is the CPU load on microservices caused by verifying tokens on every request. Each service must decode and validate the JWT signature, which is CPU-intensive. As requests grow, this verification step consumes significant CPU resources, slowing down response times.

Network bandwidth can also become a bottleneck at very large scales due to token size added to every request header, but CPU is the primary bottleneck initially.

Scaling Solutions

• Token Verification Caching: Cache verification results for tokens during their validity period to avoid repeated cryptographic checks.
• Offload Verification: Use an API gateway or dedicated authentication service to verify tokens once and pass trusted context downstream.
• Horizontal Scaling: Add more instances of microservices behind load balancers to distribute CPU load.
• Use Lightweight Tokens: Minimize JWT size by including only essential claims to reduce network overhead.
• Asynchronous Processing: For non-critical paths, defer token verification or batch requests.
• Network Optimization: Use HTTP/2 or gRPC to reduce header overhead and improve network efficiency.

Back-of-Envelope Cost Analysis

• At 10,000 users (~5,000 RPS), CPU usage for token verification can reach 30-50% on a single server.
• Each JWT token adds ~1-2 KB per request header, so at 5,000 RPS, bandwidth overhead is ~5-10 MB/s.
• At 1 million users (~500,000 RPS), bandwidth overhead approaches 500-1000 MB/s (4-8 Gbps), requiring high network capacity.
• Storage for tokens is minimal since JWTs are stateless, but caching verification results requires memory proportional to active tokens.

Interview Tip

When discussing JWT token propagation scalability, start by explaining the token verification process and its CPU cost. Then identify the bottleneck (CPU on microservices). Next, propose solutions like caching verification results or offloading verification to a gateway. Discuss network overhead and how to reduce token size. Finally, mention horizontal scaling and network optimizations. Structure your answer by identifying bottlenecks, explaining impact, and proposing targeted fixes.

Self Check

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

Answer: Since the database is the bottleneck at 1000 QPS, and traffic grows to 10,000 QPS, the first step is to add read replicas and implement connection pooling to distribute load and reduce contention. For JWT token propagation, similarly, if token verification CPU load grows 10x, first add horizontal scaling and caching of verification results before optimizing further.

Key Result

JWT token propagation first breaks at CPU load on microservices due to token verification. Caching and offloading verification, plus horizontal scaling, effectively address this bottleneck.

Practice

1. What is the main purpose of JWT token propagation in a microservices architecture?

easy

A. To encrypt all communication between microservices

B. To store user data permanently in each microservice

C. To securely share user identity information across multiple services

D. To replace API keys for service-to-service authentication

Solution

1. Step 1: Understand JWT token role

   JWT tokens carry user identity and claims securely in a compact form.

2. Step 2: Identify propagation purpose

   Propagating JWT tokens allows each microservice to verify and trust the user's identity without storing it locally.

3. Final Answer:

   To securely share user identity information across multiple services -> Option C

4. Quick Check:

   JWT propagation = share identity securely [OK]

Hint: JWT tokens carry user identity for trust across services [OK]

Common Mistakes:

• Confusing JWT propagation with data storage
• Thinking JWT encrypts all communication
• Assuming JWT replaces all authentication methods

2. Which HTTP header is commonly used to forward the JWT token between microservices?

easy

A. Authorization

B. X-Auth-Token

C. Cookie

D. Content-Type

Solution

1. Step 1: Identify standard header for tokens

   The Authorization header is the standard way to send bearer tokens like JWT in HTTP requests.

2. Step 2: Confirm other headers' roles

   X-Auth-Token is less standard, Cookie is for browser sessions, Content-Type defines data format.

3. Final Answer:

   Authorization -> Option A

4. Quick Check:

   JWT token sent in Authorization header [OK]

Hint: JWT tokens go in Authorization header as Bearer [OK]

Common Mistakes:

• Using Cookie header for token forwarding
• Confusing Content-Type with authentication headers
• Assuming custom headers like X-Auth-Token are standard

3. Consider this code snippet in a microservice forwarding a JWT token:

fetch('http://serviceB/api', {
  headers: { 'Authorization': req.headers['authorization'] }
})

What will happen if the original request has no Authorization header?

medium

A. The Authorization header is set to an empty string

B. Service B receives an Authorization header with value 'undefined'

C. The fetch call throws an error and fails

D. Service B receives the request without any Authorization header

Solution

1. Step 1: Check header forwarding code

   The code forwards req.headers['authorization'] directly as the Authorization header value.

2. Step 2: Understand missing header behavior

   If req.headers['authorization'] is undefined, the header is omitted in fetch, so Service B gets no Authorization header.

3. Final Answer:

   Service B receives the request without any Authorization header -> Option D

4. Quick Check:

   Missing header means no Authorization sent [OK]

Hint: Undefined header means no header sent, not 'undefined' string [OK]

Common Mistakes:

• Assuming 'undefined' string is sent as header value
• Expecting fetch to throw error on missing header
• Thinking header is set to empty string automatically

4. A microservice fails to verify JWT tokens from upstream services. Which of these is the most likely cause?

medium

A. The microservice does not forward the Authorization header

B. The microservice uses a different secret or public key to verify tokens

C. The microservice sends tokens in the request body instead of headers

D. The microservice caches tokens for too long

Solution

1. Step 1: Analyze verification failure causes

   Verification fails if the microservice uses a wrong secret or public key to check the JWT signature.

2. Step 2: Evaluate other options

   Not forwarding headers causes downstream issues, sending tokens in body is non-standard but not verification failure, caching affects freshness but not signature verification.

3. Final Answer:

   The microservice uses a different secret or public key to verify tokens -> Option B

4. Quick Check:

   Wrong key = verification fails [OK]

Hint: Verification needs matching secret/public key [OK]

Common Mistakes:

• Confusing forwarding issues with verification errors
• Assuming token location affects signature verification
• Ignoring key mismatch as cause of failure

5. In a microservices system, Service A receives a JWT token from a user and calls Service B, which calls Service C. To ensure secure JWT token propagation and verification, which design is best?

hard

A. Service A sends the JWT to Service B, which forwards the same JWT to Service C; each service verifies the token locally

B. Service A sends the JWT to Service B; Service B generates a new token for Service C with its own secret

C. Service A sends the JWT only to Service B; Service B calls Service C without any token

D. Service A sends the JWT to Service B; Service B stores the token and Service C fetches it from Service B when needed

Solution

1. Step 1: Understand token propagation best practice

   JWT tokens should be forwarded unchanged so each service can verify the original user identity and claims.

2. Step 2: Evaluate alternatives

   Generating new tokens breaks trust chain; skipping tokens breaks authentication; fetching tokens from another service adds complexity and risk.

3. Final Answer:

   Service A sends the JWT to Service B, which forwards the same JWT to Service C; each service verifies the token locally -> Option A

4. Quick Check:

   Forward original JWT for trust and verification [OK]

Hint: Forward original JWT unchanged for trust across services [OK]

Common Mistakes:

• Creating new tokens at intermediate services
• Not forwarding tokens to all downstream services
• Relying on token fetching instead of forwarding