Role-based access control in Microservices - System Design Exercise

Design: Role-Based Access Control (RBAC) System

Design covers the RBAC system including role management, permission assignment, and enforcement in microservices. Out of scope are user authentication mechanisms and UI design.

Functional Requirements

FR1: Users can have one or more roles assigned.

FR2: Each role has specific permissions to access resources or perform actions.

FR3: The system must enforce access control checks for microservices APIs.

FR4: Support dynamic role and permission management by administrators.

FR5: Audit logs for access attempts and changes to roles or permissions.

FR6: Support at least 100,000 users and 1,000 concurrent API requests.

FR7: API response latency for access checks should be under 100ms p99.

FR8: Ensure high availability with 99.9% uptime.

Non-Functional Requirements

NFR1: Microservices architecture with independent services.

NFR2: Centralized authorization service for role and permission management.

NFR3: Use token-based authentication (e.g., JWT) for user identity.

NFR4: Access control decisions must be fast and scalable.

NFR5: Data consistency for role and permission updates must be eventual.

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

❓ Question 6

Key Components

Authorization Service for managing roles and permissions

API Gateway or sidecar for enforcing access control

Token service issuing JWTs with embedded roles/permissions

Permission cache for fast access checks

Audit logging service

Database for storing roles, permissions, and assignments

Design Patterns

Centralized authorization with distributed enforcement

Token-based authentication with embedded claims

Caching for low-latency permission checks

Event-driven updates for cache invalidation

Audit logging with append-only storage

Reference Architecture

          +---------------------+
          |  Admin UI / CLI     |
          +----------+----------+
                     |
                     v
          +---------------------+          +---------------------+
          | Authorization       |          | Audit Logging       |
          | Service             |<---------| Service             |
          +----------+----------+          +---------------------+
                     |
                     v
          +---------------------+          +---------------------+
          | Role & Permission   |          | Database            |
          | Database            |          | (Roles, Permissions,|
          +----------+----------+          | Assignments, Logs)  |
                     |                     +---------------------+
                     v
          +---------------------+
          | Token Service       |
          +----------+----------+
                     |
                     v
          +---------------------+          +---------------------+
          | API Gateway /       |<-------->| Permission Cache    |
          | Sidecar             |          +---------------------+
          +----------+----------+
                     |
                     v
          +---------------------+
          | Microservices       |
          +---------------------+

Components

Authorization Service

Spring Boot / Node.js microservice

Manages roles, permissions, and user-role assignments. Provides APIs for admin operations.

Role & Permission Database

PostgreSQL

Stores roles, permissions, user-role mappings, and audit logs.

Token Service

OAuth2 / JWT issuer

Issues JWT tokens embedding user roles and permissions claims.

API Gateway / Sidecar

Envoy / Kong / custom middleware

Intercepts requests, validates tokens, and enforces access control using cached permissions.

Permission Cache

Redis

Caches user permissions for fast access control checks.

Audit Logging Service

Elastic Stack / Kafka + storage

Records access attempts and changes to roles or permissions for compliance.

Request Flow

1. 1. Admin creates or updates roles and permissions via Authorization Service.

2. 2. Authorization Service updates Role & Permission Database and emits events for cache invalidation.

3. 3. Token Service issues JWT tokens embedding user roles and permissions claims after user authentication.

4. 4. User sends API request with JWT token to API Gateway.

5. 5. API Gateway validates token signature and extracts roles/permissions claims.

6. 6. API Gateway checks Permission Cache for user permissions; if missing, fetches from Authorization Service.

7. 7. API Gateway enforces access control based on permissions; allows or denies request.

8. 8. Microservice processes request if authorized.

9. 9. Audit Logging Service records access decisions and role/permission changes asynchronously.

Database Schema

Entities: - User: user_id (PK), username, email - Role: role_id (PK), role_name, description - Permission: permission_id (PK), resource, action - UserRole: user_id (FK), role_id (FK), composite PK - RolePermission: role_id (FK), permission_id (FK), composite PK - AuditLog: log_id (PK), user_id (FK), action, resource, timestamp, success_flag Relationships: - User to Role is many-to-many via UserRole - Role to Permission is many-to-many via RolePermission - AuditLog references User for tracking

Scaling Discussion

Bottlenecks

Authorization Service becomes a bottleneck for frequent role/permission queries.

Permission Cache may become stale or overwhelmed with invalidation events.

API Gateway latency increases with complex permission checks.

Audit Logging volume grows rapidly with many users and requests.

Solutions

Use distributed caching with TTL and event-driven invalidation to reduce Authorization Service load.

Shard Permission Cache by user or service to improve scalability.

Offload complex permission evaluation to asynchronous jobs or precompute permission sets.

Implement log aggregation and compression; use scalable storage like Elasticsearch or cloud logging.

Interview Tips

Time: Spend 10 minutes clarifying requirements and constraints, 20 minutes designing components and data flow, 10 minutes discussing scaling and trade-offs, 5 minutes summarizing.

Explain how roles and permissions map to user access.

Describe token-based authentication and embedding claims for efficiency.

Discuss caching strategies to meet latency requirements.

Highlight audit logging importance for security and compliance.

Address how to handle updates and cache invalidation.

Mention trade-offs between consistency and availability.

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