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

1. Check access:
   • Does user U have access to camera C? (low-latency, high-QPS)
2. Set operations:
   • Which users have access to all cameras in their tenant?
3. 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
4. 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