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.