| Users | Authentication Load | Authorization Load | System Changes |
|---|---|---|---|
| 100 users | Simple login checks, single auth server | Basic role checks, simple permission store | Monolithic auth service, in-memory session store |
| 10,000 users | Increased login requests, session management | More roles and permissions, caching needed | Introduce load balancer, distributed session cache |
| 1,000,000 users | High concurrent logins, token issuance | Complex policies, attribute-based access control | Horizontal scaling of auth servers, token-based auth (JWT), distributed permission store |
| 100,000,000 users | Massive login traffic, multi-factor auth | Dynamic authorization, fine-grained policies | Global distributed auth clusters, CDN for static auth assets, real-time policy evaluation services |
Authentication vs authorization in HLD - Scaling Approaches Compared
The first bottleneck is usually the authentication service during peak login bursts. This is because it must verify credentials, generate tokens, and manage sessions, which are CPU and I/O intensive operations. Authorization checks are generally lighter and cached, so they become bottlenecks later as policies grow complex.
- Authentication: Use horizontal scaling with load balancers to handle login requests. Implement token-based authentication (e.g., JWT) to reduce session state. Use caching for session validation.
- Authorization: Cache permission data to reduce database hits. Use distributed caches like Redis. For complex policies, use policy evaluation engines that scale horizontally.
- General: Employ CDNs for static auth assets (e.g., login pages). Use rate limiting and throttling to protect auth endpoints.
Assuming 1 million users with 10% logging in daily:
- Login requests per second: ~1,000,000 * 10% / (24*3600) ≈ 1.2 QPS
- Authorization checks per second: ~1,000,000 * 10 / (24*3600) ≈ 116 QPS
- Storage: User credentials and tokens ~100MB - 1GB depending on retention
- Bandwidth: Login requests small (~1KB), authorization checks smaller (~0.5KB), total ~10-20 MB/s
Start by clearly defining authentication and authorization. Discuss their differences and dependencies. Then explain how each scales differently. Highlight bottlenecks and propose targeted solutions. Use real numbers and simple analogies like "authentication is like checking ID at a door, authorization is like checking if you can enter a room inside." Keep answers structured and focused.
Your authentication database handles 1000 QPS. Traffic grows 10x to 10,000 QPS. What do you do first?
Answer: Introduce horizontal scaling by adding more authentication servers behind a load balancer and implement token-based stateless authentication (e.g., JWT) to reduce database load. Also, add caching layers for session validation to reduce repeated DB hits.
Practice
authentication in system design?Solution
Step 1: Understand authentication purpose
Authentication is the process of confirming who the user is by checking credentials like username and password.Step 2: Differentiate from authorization
Authorization controls what the user can do after identity is confirmed, not the identity check itself.Final Answer:
Verifying the identity of a user -> Option DQuick Check:
Authentication = Verifying identity [OK]
- Confusing authentication with authorization
- Thinking authentication controls permissions
- Mixing identity verification with data encryption
Solution
Step 1: Identify authorization logic
Authorization checks what actions a user can perform, often by checking roles or permissions likeuser.role == 'admin'.Step 2: Differentiate from authentication checks
Authentication checks credentials like passwords or tokens, not roles.Final Answer:
if user.role == 'admin': -> Option CQuick Check:
Authorization checks roles/permissions [OK]
- Using password checks as authorization
- Confusing session token presence with authorization
- Checking email verification as authorization
def access_resource(user):
if not user.is_authenticated:
return "Access Denied"
if user.permission != 'read':
return "Permission Denied"
return "Resource Content"What will be the output if
user.is_authenticated is True but user.permission is 'write'?Solution
Step 1: Check authentication condition
The user is authenticated (True), so the firstifcondition fails and does not return "Access Denied".Step 2: Check authorization condition
The user's permission is 'write', which is not equal to 'read', so the secondifreturns "Permission Denied".Final Answer:
"Permission Denied" -> Option AQuick Check:
Authenticated but wrong permission = Permission Denied [OK]
- Ignoring permission check and returning resource
- Confusing authentication failure with permission failure
- Assuming 'write' permission equals 'read'
if user.is_authorized:
print("Access granted")
else:
print("Access denied")But the system always denies access even for valid users. What is the likely issue?
Solution
Step 1: Analyze authentication and authorization order
Authorization should only be checked after confirming the user is authenticated. Skipping authentication can cause authorization to fail.Step 2: Understand why access is always denied
Ifis_authorizeddepends on authentication, but authentication is missing, it will always be false or unset, denying access.Final Answer:
The code checks authorization without authenticating the user first -> Option BQuick Check:
Authenticate before authorizing [OK]
- Checking authorization without authentication
- Assuming authorization implies authentication
- Ignoring user object initialization
Solution
Step 1: Understand correct security flow
First, confirm user identity by authentication (e.g., passwords). Then, check what the user is allowed to do by authorization (e.g., roles).Step 2: Evaluate options for security best practice
Authenticate users with passwords, then authorize access based on roles before serving data follows the correct order: authenticate then authorize. Other options either reverse order, skip authorization, or skip authentication improperly.Final Answer:
Authenticate users with passwords, then authorize access based on roles before serving data -> Option AQuick Check:
Authenticate first, then authorize [OK]
- Reversing authentication and authorization order
- Skipping authorization after authentication
- Trusting session tokens without authentication
Ready to prove it?
Pass the test and this pattern moves unknown
