Design camera access-control service
Design an Access-Control Service
Context
You are tasked with designing a multi-tenant access-control service for a physical-security platform. This service will manage access for users to cameras within various organizations (tenants).
Key entities include:
- Users: Individuals who require access.
- Cameras: Devices to which access is controlled.
- Nested Groups: Hierarchical structures used for organizing users, cameras, and managing permissions.
Access is inherited through group memberships. A user gains access to a camera if there is a grant connecting a user group (to which the user belongs, directly or transitively) to a camera group (to which the camera belongs, directly or transitively). Permissions are allow-only, meaning there are no explicit deny rules. The system should support at least a "view" role, with extensibility for additional roles. Multi-tenancy must be strictly enforced via org_id isolation.
Functional Requirements
- Access Check: Determine if a specific user
Uhas access to a specific cameraC. This operation must be low-latency and support high QPS. - Set Operations: Identify all users who have access to all cameras within their respective tenant.
- Entity Management:
- Create, update, and delete users, cameras, and groups.
- Add or remove users to/from user groups (supporting nested group structures).
- Add or remove cameras to/from camera groups (supporting nested group structures).
- Grant or revoke permissions between user groups and camera groups.
Non-Functional Goals
The system should operate at a reasonable scale with the following characteristics:
- Latency: p99 latency for access checks must be under 10 ms.
- Throughput: Access-check QPS is expected to be significantly higher than write QPS.
- Scale: Support millions of users and cameras across numerous tenants. Group nesting depth can be up to 5-10 levels.
- Correctness: Strong correctness is required for access enforcement. Reasonable staleness tolerance is acceptable for list queries (e.g., "Which users have access to all cameras?").
Discussion Points
Candidates should be prepared to discuss:
- Data model choices (e.g., relational vs. graph database), including pros, cons, and the chosen design.
- API design for CRUD operations, grant management, and access checks.
- Indexing and caching strategies, particularly for the core access check and set operations.
- Consistency models and how authorization changes propagate through the system.
- Strategies for preventing cycles in nested group hierarchies.
- Scaling and sharding approaches.
- Trade-offs between precomputing transitive memberships versus on-demand traversal (e.g., using BFS).
- Methods for incremental updates of derived data and auditing.
AI interview prep
Core dilemma
Balancing ultra-low-latency, high-QPS access checks against the complexity and consistency challenges of propagating changes through a deeply nested, transitive group hierarchy.
3 tradeoffs and 3 stress tests locked
Interview prep
Unlock the interviewer X-Ray rubric, tradeoff matrix, stress tests, clarifying questions, and key concepts.
Design camera access-control service
Design an Access-Control Service
Context
You are tasked with designing a multi-tenant access-control service for a physical-security platform. This service will manage access for users to cameras within various organizations (tenants).
Key entities include:
- Users: Individuals who require access.
- Cameras: Devices to which access is controlled.
- Nested Groups: Hierarchical structures used for organizing users, cameras, and managing permissions.
Access is inherited through group memberships. A user gains access to a camera if there is a grant connecting a user group (to which the user belongs, directly or transitively) to a camera group (to which the camera belongs, directly or transitively). Permissions are allow-only, meaning there are no explicit deny rules. The system should support at least a "view" role, with extensibility for additional roles. Multi-tenancy must be strictly enforced via org_id isolation.
Functional Requirements
- Access Check: Determine if a specific user
Uhas access to a specific cameraC. This operation must be low-latency and support high QPS. - Set Operations: Identify all users who have access to all cameras within their respective tenant.
- Entity Management:
- Create, update, and delete users, cameras, and groups.
- Add or remove users to/from user groups (supporting nested group structures).
- Add or remove cameras to/from camera groups (supporting nested group structures).
- Grant or revoke permissions between user groups and camera groups.
Non-Functional Goals
The system should operate at a reasonable scale with the following characteristics:
- Latency: p99 latency for access checks must be under 10 ms.
- Throughput: Access-check QPS is expected to be significantly higher than write QPS.
- Scale: Support millions of users and cameras across numerous tenants. Group nesting depth can be up to 5-10 levels.
- Correctness: Strong correctness is required for access enforcement. Reasonable staleness tolerance is acceptable for list queries (e.g., "Which users have access to all cameras?").
Discussion Points
Candidates should be prepared to discuss:
- Data model choices (e.g., relational vs. graph database), including pros, cons, and the chosen design.
- API design for CRUD operations, grant management, and access checks.
- Indexing and caching strategies, particularly for the core access check and set operations.
- Consistency models and how authorization changes propagate through the system.
- Strategies for preventing cycles in nested group hierarchies.
- Scaling and sharding approaches.
- Trade-offs between precomputing transitive memberships versus on-demand traversal (e.g., using BFS).
- Methods for incremental updates of derived data and auditing.