Design a multi-tenant SaaS API with RBAC
PremiumAPI designHard
- Multi tenancy
- Tenant isolation
- RBAC
Quick answer
This API design interview question asks you to design a multi-tenant SaaS API with RBAC. Aim for a design that exposes a clear, consistent and safe interface, then explain the resources, requests, responses and error handling. Interviewers want to see how you name resources, version the interface and handle failure cases.
The problem
Design a multi-tenant SaaS API with RBAC for a project management tool like Asana or Jira. Each company is a tenant, one person can belong to several, and every call is checked against roles and permissions. The hard parts are guaranteed tenant isolation and fast permission checks that revoke quickly.
Each tenant (an organisation) has workspaces, projects and tasks, and a consultant may work for three clients. Admins need built-in roles (owner, admin, member, guest) and, on the Enterprise plan, custom roles. Integrations call the same API with API keys, and admins must see who did what.
What must a multi-tenant SaaS API with RBAC do?
- Tenancy: Every resource belongs to exactly one organisation; a user switches organisations without logging in again.
- Roles: Built-in roles plus up to 50 custom roles per organisation, each a set of permissions such as project.create or task.delete.
How well must it do it?
- Isolation: A bug in one endpoint must not expose another tenant's rows; isolation is enforced in more than one layer.
- Latency: Permission checks add under 5 ms at p99 to each request.
What scale should you design for?
Use these numbers in your estimates.
The scale numbers unlock with this questionUnlock
Key concepts
- Multi tenancy
- Tenant isolation
- RBAC
- Custom roles
- Scoped API keys
- Per tenant rate limits
How you’ll practise
- Use cases
- Resources
- Endpoints
- Errors, auth and limits
- Versioning
- Wrap-up
Lala, personalized to you, gives a hint when you ask and reviews your design when you are ready.
What do interviewers look for?
In any API design round.
- Starts from the clients and the use cases
- Names resources and operations consistently
- Defines request and response shapes and status codes
- Covers authentication, rate limits and idempotency
- Plans pagination, filtering and versioning
- Explains how clients learn about and recover from errors
Questions people ask about this interview question
- Which design type is this question?
- It is an API design question. You design a multi-tenant SaaS API with RBAC and explain your choices the way you would in an interview.
- Is this question asked at entry level?
- It is marked Hard. It suits engineers preparing for senior interviews, where you are expected to drive the discussion and go deep on trade-offs.
- What should I cover first?
- Start with the clients, the main use cases and the resources they need. Agree on scope with the interviewer before you design anything.
- Can I practise it for free?
- It is a premium question. Sign up and unlock it once for 10 credits; it then stays unlocked. When you finish, Lala, your personalized AI mentor, can review your design for 30 credits.
Related questions
Updated · Written by the SevyDevy team