Skip to content

Fastapi rbac

System Design Task: FastAPI Role-Based Access Control (RBAC)

Problem Statement

Design and implement a production-grade Role-Based Access Control (RBAC) system for a FastAPI application. The system must provide fine-grained authorization, support multi-tenancy, and scale to handle thousands of permission checks per second with minimal latency impact.

You are expected to design this as if it were going into production at enterprise scale.

Functional Requirements

Your design must support:

  1. Role Management

  2. Define roles with hierarchical permissions:

    • Super Admin
    • Admin
    • Manager
    • User
    • Guest/Viewer
  3. Support custom role creation

  4. Role inheritance (Manager inherits User permissions)

  5. Permission Types

  6. Route-level permissions: Control access to API endpoints

  7. Resource-level permissions: CRUD operations on specific resources
  8. Field-level permissions: Control access to specific data fields

  9. Data-scope permissions: Filter data based on ownership/tenant

  10. Authorization Models

  11. Role-Based Access Control (RBAC)

  12. Optional: Attribute-Based Access Control (ABAC) extension

  13. Support for permission groups/bundles

  14. Multi-Tenancy Support

  15. Tenant isolation for SaaS applications

  16. Tenant-specific role definitions

  17. Cross-tenant admin capabilities

  18. APIs

  19. User-Role assignment API

  20. Role-Permission management API
  21. Permission check API

  22. Audit log API

  23. Integration Points

  24. JWT token-based authentication

  25. OAuth2 scopes compatibility
  26. Middleware-based enforcement
  27. Dependency injection pattern

Non-Functional Requirements

Your system must meet the following constraints:

  1. Performance

  2. Permission check latency ≤ 5ms (P99)

  3. Support 10,000+ permission checks/second per instance

  4. Cache hit ratio ≥ 95% for repeated checks

  5. Scalability

  6. Support 100,000+ users

  7. Support 1,000+ roles

  8. Support 10,000+ permissions

  9. Availability

  10. ≥ 99.9% uptime

  11. Graceful degradation when cache unavailable

  12. No single point of failure

  13. Security

  14. Principle of least privilege by default

  15. Audit trail for all permission changes
  16. Token invalidation on role changes

  17. Protection against privilege escalation

  18. Maintainability

  19. Clear separation of concerns

  20. Easy to add new permissions
  21. Migration support for permission changes

What You Should Deliver

Provide a practical, production-oriented design that includes:

  1. Requirements clarification & assumptions

  2. Database schema design

  3. User-Role relationships
  4. Role-Permission mappings

  5. Tenant isolation strategy

  6. Architecture components

  7. Core RBAC service
  8. Caching layer

  9. Middleware/dependency design

  10. FastAPI implementation patterns

  11. Dependency injection for permission checks
  12. Decorator-based route protection

  13. Request context management

  14. Caching strategy

  15. Permission cache design
  16. Cache invalidation patterns

  17. Fallback behavior

  18. Multi-tenancy implementation

  19. Tenant context propagation

  20. Cross-tenant queries

  21. Audit and compliance

  22. Permission change tracking

  23. Access attempt logging

  24. Testing strategy

  25. Unit testing permissions

  26. Integration testing authorization flows

  27. Code examples

  28. Complete working implementation

  29. Reusable patterns and utilities

  30. Trade-offs

    • Explain design decisions and alternatives

Expectations

  • Be concrete (include actual Python code, SQL schemas, Redis patterns)
  • Provide working code examples that can be adapted
  • Follow FastAPI best practices (dependency injection, async patterns)
  • Use type hints and Pydantic models
  • Consider real-world edge cases (token expiry, role conflicts, etc.)
  • Prefer simple, maintainable designs over clever abstractions

Evaluation Criteria

  • Correctness of authorization logic
  • Performance under load
  • Code quality and maintainability
  • Security considerations
  • Practical applicability to real projects

Interview Kit

Read first: Solution · API design patterns · Caching §3 invalidation

Curveballs. The interviewer changes one thing mid-design. The hint in italics is what a strong answer reaches for:

  1. An admin removes a role, and the user keeps access for 10 more minutes. (Permission-cache invalidation, token lifetime vs. revocation.)
  2. A request for /tenants/B/invoices succeeds with a tenant-A token. Where is the check missing? (Tenant scoping in every query, not only in the route.)
  3. Customers want custom roles. What changes in your model?
  4. Auditors ask who could access payroll data on a given date last year.

Must answer (security, privacy, operations):

  • Default deny, tests for every route's permission, and object-level (IDOR) checks
  • An audit log of permission changes and access to sensitive resources

Phase it (MVP → Growth → Scale): MVP: roles in Postgres with a FastAPI dependency per route. Growth: tenant-scoped roles, a permission cache with invalidation. Scale: a policy engine (OPA/Cedar/Zanzibar-style) for relationships and custom roles.

Score yourself with the rubric.