Centralized vs distributed auth in Microservices - Scaling Approaches Compared

Scalability Analysis - Centralized vs distributed auth

Growth Table: Centralized vs Distributed Auth

Users	Centralized Auth	Distributed Auth
100 users	Single auth server handles requests easily; low latency	Each service manages auth locally; simple token validation
10,000 users	Auth server load increases; may need load balancing; DB queries rise	Token issuance centralized; local validation reduces auth server load
1,000,000 users	Auth server becomes bottleneck; DB and network saturated; latency rises	Distributed token validation scales well; token revocation and sync become complex
100,000,000 users	Single auth cluster struggles; needs sharding, caching, and global load balancing	Highly scalable; requires robust token management, sync, and security policies

First Bottleneck

In centralized auth, the authentication server and its database become the first bottleneck as user count grows. It handles all login and token issuance, causing CPU, memory, and DB query overload.

In distributed auth, the main bottleneck shifts to token management complexity, especially token revocation and synchronization across services, which can cause inconsistencies and security risks.

Scaling Solutions

• Centralized Auth: Use horizontal scaling with multiple auth servers behind load balancers; implement caching for session data; use read replicas for DB; shard user data by region or user ID.
• Distributed Auth: Use stateless tokens (e.g., JWT) for local validation; implement token revocation lists with fast distributed caches like Redis; synchronize token state with event-driven messaging; enforce strict token expiry policies.
• Use CDNs and edge servers to reduce latency for auth requests globally.

Back-of-Envelope Cost Analysis

Assuming 1 million users with 10% active per second = 100,000 auth requests/sec peak.

• Centralized auth server: Each server handles ~3000 QPS, so ~34 servers needed.
• Database: Needs to handle 100,000 QPS; use sharding and read replicas.
• Network bandwidth: Assuming 1 KB per auth request, 100 MB/s bandwidth needed.
• Distributed auth: Token validation is local, reducing auth server load to token issuance only (e.g., 10% of requests), lowering server count.

Interview Tip

Start by defining the auth model clearly. Discuss trade-offs between centralized and distributed approaches. Identify bottlenecks at each scale. Propose concrete scaling techniques matching bottlenecks. Highlight security and consistency challenges. Use real numbers to justify decisions.

Self Check

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

Answer: Add read replicas and implement caching to reduce DB load before scaling application servers. Consider sharding if growth continues.

Key Result

Centralized auth faces bottlenecks at the auth server and database as users grow, requiring horizontal scaling and caching. Distributed auth scales better for validation but adds complexity in token management and revocation synchronization.

Practice

1. What is the main characteristic of centralized authentication in microservices?

easy

A. No authentication is required between services

B. Each microservice verifies user identity independently

C. Authentication is done by the client application only

D. A single service handles all user login and identity verification

Solution

1. Step 1: Understand centralized authentication

   Centralized authentication means one dedicated service manages all login and identity checks for the system.

2. Step 2: Compare with other options

   Distributed auth where each service verifies independently, client-only auth, or no auth are not centralized.

3. Final Answer:

   A single service handles all user login and identity verification -> Option D

4. Quick Check:

   Centralized auth = single service [OK]

Hint: Centralized means one place handles all auth [OK]

Common Mistakes:

• Confusing centralized with distributed auth
• Thinking each service handles login in centralized auth
• Assuming client-only authentication is centralized

2. Which of the following is a typical token used in distributed authentication?

easy

A. OAuth 2.0 access token

B. SQL query string

C. HTML cookie without signature

D. Plain text password

Solution

1. Step 1: Identify token types in distributed auth

   Distributed authentication commonly uses tokens like OAuth 2.0 access tokens to verify identity without contacting a central service each time.

2. Step 2: Eliminate incorrect options

   SQL queries, unsigned cookies, and plain text passwords are not secure tokens used for distributed auth.

3. Final Answer:

   OAuth 2.0 access token -> Option A

4. Quick Check:

   Distributed auth token = OAuth 2.0 token [OK]

Hint: OAuth tokens are standard for distributed auth [OK]

Common Mistakes:

• Confusing SQL queries with tokens
• Using unsigned cookies as secure tokens
• Thinking plain text passwords are tokens

3. Consider a microservice system where each service validates JWT tokens locally without contacting a central auth server. What is the main advantage of this approach?

medium

A. Reduced latency and less dependency on a central service

B. Simpler token revocation management

C. Centralized control over user sessions

D. No need for token expiration

Solution

1. Step 1: Understand local JWT validation

   When services validate JWT tokens locally, they avoid network calls to a central auth server, reducing latency and dependency.

2. Step 2: Analyze other options

   Token revocation is harder locally, centralized control over user sessions is lost, and tokens still need expiration.

3. Final Answer:

   Reduced latency and less dependency on a central service -> Option A

4. Quick Check:

   Distributed auth local validation = less latency [OK]

Hint: Local token checks speed up requests [OK]

Common Mistakes:

• Assuming token revocation is easier locally
• Thinking local validation means centralized control
• Ignoring token expiration needs

4. A microservice system uses centralized authentication but experiences frequent downtime of the auth service. What is the best way to fix this issue?

medium

A. Use plain text passwords for faster login

B. Remove authentication completely

C. Implement caching of authentication tokens in services

D. Make each service validate tokens independently without central auth

Solution

1. Step 1: Identify problem with centralized auth downtime

   Downtime of the central auth service causes failures in login or token validation.

2. Step 2: Choose a solution to reduce dependency

   Caching tokens locally in services reduces calls to the central auth, improving availability without removing auth or security.

3. Final Answer:

   Implement caching of authentication tokens in services -> Option C

4. Quick Check:

   Fix downtime by caching tokens [OK]

Hint: Cache tokens to reduce auth service calls [OK]

Common Mistakes:

• Removing authentication entirely
• Switching to insecure plain text passwords
• Switching to distributed auth without planning

5. You are designing a large microservices system that requires high security and low latency. Which authentication approach best balances these needs?

hard

A. Centralized authentication with synchronous calls for every request

B. Distributed authentication using signed tokens validated locally with periodic revocation checks

C. No authentication to maximize speed

D. Centralized authentication with no token expiration

Solution

1. Step 1: Analyze security and latency needs

   High security requires token validation and revocation; low latency requires avoiding frequent central calls.

2. Step 2: Evaluate options

   Distributed authentication using signed tokens validated locally with periodic revocation checks uses signed tokens validated locally to reduce latency and periodic revocation checks to maintain security. Centralized authentication with synchronous calls for every request causes latency, no authentication is insecure, and centralized authentication with no token expiration risks stale sessions.

3. Final Answer:

   Distributed authentication using signed tokens validated locally with periodic revocation checks -> Option B

4. Quick Check:

   Balance security and speed with distributed tokens [OK]

Hint: Use local token checks plus revocation for security and speed [OK]

Common Mistakes:

• Choosing no authentication for speed
• Ignoring token expiration and revocation
• Relying on central auth for every request causing latency