Design an access-control service for users, cameras, and nested groups that can answer queries like: Does user U have access to camera C? and Which users have access to all cameras? Cover data model choices (relational vs. graph), APIs, indexing and caching strategies, consistency and authorization change propagation, cycle prevention in group hierarchies, scaling and sharding, precomputing transitive memberships versus on-demand traversal (e.g., BFS), and approaches for incremental updates and auditing.

This question evaluates a candidate's competency in large-scale system design, data modeling for access control, distributed consistency, and API and caching strategies required for low-latency authorization checks.

How do I approach System Design interview questions?

System Design questions require understanding of core concepts and practice. PracHub provides solutions with explanations to help you master system design interviews.

What difficulty level is this interview question?

This is a hard difficulty System Design question, commonly asked during Technical Screen rounds at Verkada.

What role is this question designed for?

This question is commonly asked for Software Engineer candidates at Verkada during technical interviews.

Design camera access-control service | Verkada Interview Question

Design an Access-Control Service (Users, Cameras, Nested Groups)

Context

You are building a multi-tenant access-control service for a physical-security platform. Tenants (organizations) have:

Users (people)
Cameras (devices)
Nested groups for organization, user, and camera management

Access is inherited via group memberships. A user has access to a camera if they are connected via grants between user groups and camera groups, considering transitive membership (nested groups).

Assume permissions are allow-only (no explicit denies), with at least one role such as "view"; feel free to mention how to extend to additional roles.

Functional Requirements

Check access:
- Does user U have access to camera C? (low-latency, high-QPS)
Set operations:
- Which users have access to all cameras in their tenant?
Manage entities:
- Create/update/delete users, cameras, and groups
- Add/remove users to/from user groups (nested)
- Add/remove cameras to/from camera groups (nested)
- Grant/revoke permissions from user groups to camera groups
Multi-tenancy isolation by org_id.

Non-Functional Goals (assume reasonable scale)

Latency: p99 < 10 ms for the access check
Throughput: access-check QPS >> write QPS
Scale: up to millions of users/cameras across many tenants; group depth up to ~5–10
Strong correctness for enforcement; reasonable staleness tolerance for list queries

What to Cover

Data model choices: relational vs. graph (pros/cons) and your chosen design
API design (CRUD, grants, access-check endpoints)
Indexing and caching strategies for the two core queries
Consistency model and authorization change propagation
Cycle prevention in nested group hierarchies
Scaling and sharding strategy
Precomputing transitive memberships vs. on-demand traversal (e.g., BFS)
Incremental update approaches for derived data and auditing

Context

You are building a multi-tenant access-control service for a physical-security platform. Tenants (organizations) have:

Users (people)

Cameras (devices)

Nested groups for organization, user, and camera management

Access is inherited via group memberships. A user has access to a camera if they are connected via grants between user groups and camera groups, considering transitive membership (nested groups).

Assume permissions are allow-only (no explicit denies), with at least one role such as "view"; feel free to mention how to extend to additional roles.

Functional Requirements

Check access:

Does user U have access to camera C? (low-latency, high-QPS)

Set operations:

Which users have access to all cameras in their tenant?

Manage entities:

Create/update/delete users, cameras, and groups
Add/remove users to/from user groups (nested)
Add/remove cameras to/from camera groups (nested)
Grant/revoke permissions from user groups to camera groups

Multi-tenancy isolation by org_id.

What to Cover

Data model choices: relational vs. graph (pros/cons) and your chosen design

API design (CRUD, grants, access-check endpoints)

Indexing and caching strategies for the two core queries

Consistency model and authorization change propagation

Cycle prevention in nested group hierarchies

Scaling and sharding strategy

Precomputing transitive memberships vs. on-demand traversal (e.g., BFS)

Incremental update approaches for derived data and auditing

Design camera access-control service

Quick Overview

Design an Access-Control Service (Users, Cameras, Nested Groups)

Context

Functional Requirements

Non-Functional Goals (assume reasonable scale)

What to Cover

Solution

Submit Your Answer to Earn 20XP

Design camera access-control service

Quick Overview

Design an Access-Control Service (Users, Cameras, Nested Groups)

Context

Functional Requirements

Non-Functional Goals (assume reasonable scale)

What to Cover

Solution

Submit Your Answer to Earn 20XP