Design a Multi-Tenant SaaS Workspace Permission Service
We want to build an internal authorization service that validates whether users belonging to different business organizations can access specific workspace resources. The system needs to sit in front of various product microservices to enforce role-based and attribute-based security boundaries. You will draw the core components, data paths, and data models on the board.
This brief is incomplete on purpose, as it would be in a real interview. Ask the interviewer about the users, the features, the targets and the traffic. Whatever you uncover is added below.
- Users must be able to authenticate and request validation for a specific action on a workspace resource.
- Administrators must be able to assign roles to users within the context of their specific tenant workspace.
- The system must support custom roles defined by tenant administrators alongside default system roles.
- Guest invitations
- Evaluation latency
- Tenant isolation
- Daily active tenants
- Actions per user
- Record size
- The API contracts for permission evaluation and role management
- The database schema supporting multi-tenant isolation and role hierarchies
- The request path and caching strategy for a low-latency authorization check
The design clearly enforces boundaries so that database queries and cache lookups always include tenant identifiers, preventing cross-tenant data leaks.
The candidate introduces an effective caching layer or local evaluation approach to keep synchronous check times well within the tight latency budget.
The relational or graph schema cleanly connects users, tenants, roles, and resources without excessive join complexity during checks.
The design addresses how cached permission evaluations are invalidated or updated promptly when an administrator modifies a user role.
Every functional requirement in the brief is visibly served by something on the board, and the non-functional targets are addressed rather than ignored.
Components are labelled, data flows are drawn as connections between them, and the direction of each flow is unambiguous.
Do not write any code or focus on language-specific frameworks. Keep the design focused on the core access evaluation path and tenant isolation boundaries. Multi-region replication is out of scope for this discussion.
- Views
- 2