RBAC

RBAC (Role-Based Access Control) assigns permissions to roles like 'admin', 'editor', 'viewer' — users inherit permissions through their role membership. Instead of managing permissions for 10,000 users individually, you manage 5-10 roles. RBAC is the most widely implemented access control model because it maps directly to organizational structure. AWS IAM, Kubernetes, and every enterprise SaaS product uses RBAC as the foundation of their permission system.

Why This Matters

Without RBAC, adding a new employee means manually assigning dozens of individual permissions. With 10,000 employees, that is unmanageable. RBAC reduces this to: assign the 'engineer' role, which already has the right permissions. When a permission needs to change across all engineers, you update the role once. In system design interviews, RBAC is the expected starting point for access control. Interviewers test whether you understand role hierarchy, permission inheritance, and when RBAC is insufficient (requiring ABAC or ReBAC).

The Building Blocks

• Roles: Named groups of permissions: admin, editor, viewer, billing-admin. Roles map to job functions. A role is a collection of (resource, action) pairs.
• Permission Assignment: Permissions are assigned to roles, not users. A permission is a (resource, action) pair: (documents, write), (users, delete). The mapping is stored in a roles table.
• Role Hierarchy: Roles can inherit from other roles. Admin inherits all editor permissions, editor inherits all viewer permissions. This prevents duplicate permission definitions.
• Principle of Least Privilege: Users should have the minimum permissions necessary. Start with 'viewer' and escalate only when needed. Regularly audit and revoke unused permissions.
• Multi-Tenancy: In SaaS, roles are scoped to a tenant. A user can be 'admin' in Org A but 'viewer' in Org B. The (user, role, tenant) triple is the permission unit.

Under the Hood

An RBAC system consists of three database tables: users, roles, and user_roles (the join table). Permissions are stored as role_permissions: (role_id, resource, action). When a user makes a request, the system looks up their roles via user_roles, then checks if any of those roles have a matching (resource, action) permission.

For performance, role lookups are cached. A typical pattern: on login, fetch all of the user's roles and permissions, serialize them into the JWT claims or cache them in Redis with the user_id as key. On each request, the authorization middleware reads from cache rather than hitting the database. Cache invalidation happens when roles change — publish a role-change event that clears the affected user's cached permissions.

Role hierarchy is implemented as a directed acyclic graph. When checking permissions, the system walks up the hierarchy: if the user has 'editor' role and 'editor' inherits from 'viewer', they get all viewer permissions automatically. This is resolved at cache-build time, not per-request.

How Companies Actually Do This

AWS IAM uses RBAC with policy documents. Roles like 'S3ReadOnly' bundle permissions. Users and services assume roles to get temporary credentials. Every AWS API call checks IAM.

Kubernetes uses RBAC for cluster access. ClusterRoles define permissions (list pods, create deployments), RoleBindings assign roles to users or service accounts within namespaces.

Stripe implements RBAC for dashboard access. Team members are assigned roles (developer, administrator, analyst) that control access to payments, refunds, and account settings.

Common Pitfalls

1. Role explosion — creating hundreds of granular roles defeats the purpose of RBAC. If you have as many roles as users, switch to ABAC or ReBAC
2. Not scoping roles to tenants in multi-tenant systems — a user who is admin in their own org should not have admin access to other orgs
3. Caching roles without invalidation — when a role is revoked, the user retains access until the cache expires, which can be a security gap

Interview Questions Worth Practicing

1. How would you design an RBAC system for a SaaS product with thousands of organizations?
2. When does RBAC break down, and what would you use instead?
3. How do you handle permission caching while ensuring revoked access is enforced promptly?

The Tradeoffs

• Simplicity vs Expressiveness: RBAC is simple to implement and audit, but cannot express 'users can only edit resources they own' or 'managers can approve expenses under $10K' — those require ABAC.
• Coarse vs Fine-Grained: Fewer roles are easier to manage but may over-privilege users. More roles give finer control but increase management complexity.
• Static vs Dynamic: Static role assignments are predictable but inflexible. Dynamic role resolution (based on context like time, location) adds flexibility but makes the system harder to reason about.

How to Explain This in an Interview

Here is how I would explain RBAC in a system design interview:

RBAC is the standard way to manage permissions at scale. Instead of assigning permissions to each user individually, I assign permissions to roles and users to roles. In a typical SaaS system, I would have roles like admin, editor, and viewer — each scoped to an organization (tenant). The permission check is simple: on each request, look up the user's roles (cached in Redis or JWT claims), check if any role grants the required (resource, action) permission. For role hierarchy, admin inherits editor inherits viewer, so I resolve the full permission set once at login and cache it. If asked when RBAC is insufficient, I would mention ownership-based rules — 'users can only edit their own documents' requires ABAC or ReBAC, not just role checks.

Related Topics

• Authorization
• Authentication
• SSO
• API Gateway

Original DosiBridge notes for RBAC

This section is written specifically for this page, not copied from a general system-design checklist. The useful way to study RBAC is to connect the concept to a production service where growth exposes the first weak assumption in the original design. That framing changes the design discussion from definitions to operating choices.

What makes this topic distinct

• Contract Evolution: For RBAC, decide the contract evolution before choosing tools; otherwise the design looks clean but fails when rbac changes.
• Idempotency: For RBAC, decide the idempotency before choosing tools; otherwise the design looks clean but fails when rbac changes.
• Pagination: For RBAC, decide the pagination before choosing tools; otherwise the design looks clean but fails when rbac changes.
• Error Shape: For RBAC, decide the error shape before choosing tools; otherwise the design looks clean but fails when rbac changes.
• Consumer Compatibility: For RBAC, decide the consumer compatibility before choosing tools; otherwise the design looks clean but fails when rbac changes.

Production review question

If a team adopts RBAC, what observable signal proves it helped instead of only making the architecture diagram more fashionable?

Practical metric to track

Track rbac health as a named dashboard or review item: combine one user-facing metric, one saturation metric, and one correctness metric. For RBAC, this keeps the discussion grounded in behavior that can be measured after deployment instead of generic advice that sounds good in an interview but never gets verified.