Role-based access control in Microservices - Scalability & System Analysis

Scalability Analysis - Role-based access control

Growth Table: Role-based Access Control (RBAC) in Microservices

Users	Roles	Permissions	Access Checks per Second	System Changes
100	10	50	200	Simple centralized auth service; direct DB queries for access checks
10,000	100	500	20,000	Introduce caching for permissions; use token-based auth (JWT); microservices query cache
1,000,000	1,000	5,000	2,000,000	Distributed cache (e.g., Redis); auth service scaled horizontally; async permission updates; token introspection service
100,000,000	10,000	50,000	200,000,000	Sharded permission storage; global CDN for token validation; edge caching; fine-grained permission microservices; event-driven updates

First Bottleneck

The first bottleneck is the authorization service database that stores roles and permissions. As user count and access checks grow, frequent permission lookups cause high read load and latency. Direct DB queries for each access check become too slow and resource-heavy.

Scaling Solutions

• Caching: Use in-memory caches (e.g., Redis) to store user roles and permissions for fast access.
• Token-based Auth: Use JWT tokens embedding roles/permissions to reduce calls to auth service.
• Horizontal Scaling: Run multiple instances of the auth service behind a load balancer.
• Sharding: Partition role and permission data by user groups or regions to distribute load.
• Event-driven Updates: Use message queues to update caches asynchronously when roles or permissions change.
• Edge Caching and CDN: For global scale, cache tokens and permission data closer to users.

Back-of-Envelope Cost Analysis

• At 1M users with 2M access checks/sec, assuming 1KB per permission cache entry, Redis needs ~2GB RAM for hot data.
• Network bandwidth for 2M requests/sec with 1KB payload = ~2GB/s (~16Gbps), requiring high network capacity.
• Auth service instances: each handles ~5,000 QPS, so ~400 instances needed at peak.
• Storage for roles/permissions: tens of GBs, depending on complexity and history retention.

Interview Tip

Start by explaining the RBAC components: users, roles, permissions, and access checks. Then discuss how load grows with users and requests. Identify the database as the first bottleneck. Propose caching and token-based auth to reduce load. Finally, mention horizontal scaling and sharding for very large scale. Keep answers structured and focused on bottlenecks and solutions.

Self Check

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

Answer: Introduce caching for roles and permissions to reduce direct database queries. This lowers DB load and improves response time before scaling DB or services.

Key Result

The database storing roles and permissions is the first bottleneck as user and request volume grows; caching and token-based authorization are key to scaling RBAC in microservices.

Practice

1. What is the main purpose of Role-Based Access Control (RBAC) in microservices?

easy

A. To encrypt data between microservices

B. To monitor network traffic for security threats

C. To assign permissions to users based on their roles

D. To deploy microservices automatically

Solution

1. Step 1: Understand RBAC concept

   RBAC assigns permissions to users based on their roles, simplifying access management.

2. Step 2: Identify RBAC purpose in microservices

   In microservices, RBAC controls who can access which service or API based on roles.

3. Final Answer:

   To assign permissions to users based on their roles -> Option C

4. Quick Check:

   RBAC = Role-based permission assignment [OK]

Hint: RBAC controls access by roles, not by encryption or deployment [OK]

Common Mistakes:

• Confusing RBAC with encryption
• Thinking RBAC monitors network traffic
• Assuming RBAC automates deployment

2. Which of the following is the correct way to represent a role in an RBAC system for microservices?

easy

A. {"service": "admin", "level": 5}

B. {"role": "admin", "permissions": ["read", "write"]}

C. {"user": "admin", "access": "full"}

D. {"permission": "admin", "role": "read"}

Solution

1. Step 1: Identify correct role structure

   A role should have a name and a list of permissions it grants.

2. Step 2: Match structure to options

   {"role": "admin", "permissions": ["read", "write"]} correctly shows a role with permissions as a list, matching RBAC design.

3. Final Answer:

   {"role": "admin", "permissions": ["read", "write"]} -> Option B

4. Quick Check:

   Role = name + permissions list [OK]

Hint: Roles have permissions list; user or service keys are incorrect here [OK]

Common Mistakes:

• Confusing user with role
• Using 'permission' as role name
• Assigning access level instead of permissions

3. Given this simplified RBAC check in a microservice:

def can_access(user_role, action):
    permissions = {
        "user": ["read"],
        "admin": ["read", "write", "delete"]
    }
    return action in permissions.get(user_role, [])

print(can_access("user", "delete"))

What is the output?

medium

A. None

B. True

C. KeyError

D. False

Solution

1. Step 1: Understand permissions dictionary

   The "user" role has only ["read"] permission, no "delete".

2. Step 2: Check if "delete" is in user permissions

   Since "delete" is not in ["read"], the function returns False.

3. Final Answer:

   False -> Option D

4. Quick Check:

   "delete" in user permissions = False [OK]

Hint: Check if action is in role's permission list [OK]

Common Mistakes:

• Assuming all actions allowed for user
• Expecting KeyError for missing keys
• Confusing True/False return values

4. A microservice uses this RBAC check:

def check_access(role, permission):
    role_permissions = {
        "editor": ["read", "write"],
        "viewer": ["read"]
    }
    return permission in role_permissions[role]

print(check_access("admin", "write"))

What is the problem and how to fix it?

medium

A. KeyError occurs; fix by using role_permissions.get(role, [])

B. SyntaxError due to missing colon; add colon after function

C. Returns False incorrectly; add "admin" role to dictionary

D. Returns True incorrectly; remove "write" from editor permissions

Solution

1. Step 1: Identify error cause

   Accessing role_permissions["admin"] causes KeyError because "admin" key is missing.

2. Step 2: Fix by safe dictionary access

   Use role_permissions.get(role, []) to return empty list if role missing, avoiding error.

3. Final Answer:

   KeyError occurs; fix by using role_permissions.get(role, []) -> Option A

4. Quick Check:

   Missing key causes KeyError; get() avoids it [OK]

Hint: Use get() to avoid KeyError on missing roles [OK]

Common Mistakes:

• Adding roles without permissions
• Confusing syntax errors with runtime errors
• Ignoring missing key errors

5. In a microservices architecture, where is the best place to enforce RBAC to ensure scalability and security?

hard

A. At the API Gateway before requests reach microservices

B. On the client side before sending requests

C. Only in the database layer with SQL permissions

D. Inside each microservice individually

Solution

1. Step 1: Consider scalability and security needs

   Enforcing RBAC centrally avoids duplication and reduces risk of inconsistent checks.

2. Step 2: Identify best enforcement point

   API Gateway is the central entry point, ideal for RBAC enforcement before microservices.

3. Final Answer:

   At the API Gateway before requests reach microservices -> Option A

4. Quick Check:

   Central RBAC at API Gateway = scalable & secure [OK]

Hint: Enforce RBAC centrally at API Gateway for best results [OK]

Common Mistakes:

• Enforcing RBAC only in microservices causes duplication
• Relying on client-side enforcement is insecure
• Using database permissions alone misses API-level control