Design camera access-control service

Last updated: Mar 29, 2026

Quick Overview

This interview question evaluates requirements, scale assumptions, API/data design, architecture, trade-offs, failure modes, and rollout in a realistic interview setting. A strong answer for Design camera access-control service states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.

|Home/System Design/Verkada

Design camera access-control service

Verkada

Aug 8, 2025, 12:00 AM

hardSoftware EngineerTechnical ScreenSystem Design

18

0

Design camera access-control service

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

Constraints & Assumptions

Preserve the scope, facts, inputs, and requested outputs from the prompt above.
If the prompt leaves a detail unspecified, state a reasonable assumption before relying on it.
Keep the answer interview-ready: concise enough to present, but concrete enough to implement or evaluate.

Clarifying Questions to Ask Guidance

Clarify users, core use cases, read/write patterns, scale, latency, availability, and data retention.
State explicit assumptions before making sizing or architecture decisions.
Prioritize the functional path first, then address reliability, security, observability, and rollout.

What a Strong Answer Covers Guidance

A scoped requirements summary with concrete non-goals and success metrics.
API, data model, architecture, consistency, capacity, and operations.
Reasoned trade-offs among simple and scalable designs, including bottlenecks and failure modes.
A validation, monitoring, migration, and launch plan appropriate for the risk level.

Follow-up Questions Guidance

What breaks first at 10x traffic or data volume?
How would you degrade gracefully during dependency failures?
What metrics and alerts would prove the design is healthy after launch?

Submit Your Answer to Earn 20XP

Sign in to leave a comment

Loading comments...

Browse More Questions

More System Design•More Verkada•More Software Engineer•Verkada Software Engineer•Verkada System Design•Software Engineer System Design

Your design canvas — auto-saved