Authorization and permission systems

Designing who can do what: authentication versus authorization, RBAC, ABAC and relationship-based access control, Google Zanzibar-style permission services, sharing and inheritance, checking permissions fast, filtering lists, and auditing.

Reading is half of it. See this used in a real interview: walk through Design Dropbox →

Authentication answers "who are you?"; authorization answers "may you do this?". The second is harder. "Share this folder with Alice as editor", "only workspace admins can delete channels", "followers can see this private account's posts": each product feature adds permission rules, and every request must check them quickly and correctly. Questions about Google Drive, Dropbox, Slack and Docs often include a permissions model, and getting it right avoids the most damaging class of bugs: users seeing data they should not.

Models

Most products combine them: RBAC for organisation-level roles, ReBAC for sharing and inheritance, a few attribute conditions.

Relationship-based access and Zanzibar

Google's Zanzibar (behind Drive, YouTube, Calendar and more) stores relationship tuples:

doc:readme#viewer@user:alice
folder:eng#editor@group:eng-team#member
doc:readme#parent@folder:eng

and a schema of rules such as "editors are also viewers" and "viewers of a folder are viewers of its documents". A permission check ("can Alice view doc:readme?") walks this graph. Open-source systems inspired by it (SpiceDB, OpenFGA and others) offer the same model as a service. See graph data.

Benefits: one consistent model for sharing, groups, nesting and inheritance across products; centralised auditing; easy "who has access?" queries.

Making checks fast

Permission checks happen on almost every request, often many per page:

• Cache check results briefly, and cache group memberships.
• Precompute or denormalise deep group nesting (flattened membership) for hot paths.
• Run checks in parallel, and batch checks for lists.
• Keep the permission service close to the services that call it, replicated per region.

The new enemy problem

Caching and replication cause a subtle bug: Alice removes Bob from a document, then adds secret content. If the content change is checked against a stale permission replica that still lists Bob, Bob sees the secret. Zanzibar solves this with consistency tokens ("zookies"): the content write records a token, and later checks are evaluated at a permission snapshot at least as new as that token. In simpler systems, check against the primary for sensitive changes, or invalidate caches synchronously on revocation.

Filtering lists

"Show me all documents I can see" cannot check every document. Options:

• Look up the user's accessible resources from the permission graph (reverse lookup), then fetch them.
• Store access lists (or group ids) on resources in the search index and filter by the user's groups at query time.
• For per-tenant data, scope by tenant first, then check within. See multi-tenancy.

Always re-check permissions on the final items, since indexes can be stale.

Where to enforce

• At the edge or gateway: coarse checks (authenticated? has the scope for this API?). See API gateways.
• In each service: fine-grained checks on the actual resource, never trusting the client's claims about ownership.
• In the data layer: row-level security as a backstop.

Defence in depth matters: a single missed check in one endpoint is a data leak.

Sharing features

• Links: "anyone with the link can view" is a relationship with a public subject or a secret token; let owners revoke and expire links.
• Inheritance: permissions flow from folders to contents; moving a file changes who can see it, so show a warning.
• External sharing: policies at the organisation level may forbid sharing outside the domain.

See Design Dropbox and Design Google Docs.

Auditing

Log every permission change (who granted what to whom, when) and, for sensitive resources, every access. Enterprises need access reviews ("who can see payroll?"). See security and auth.

In the interview

For a sharing product: model permissions as relationship tuples with inheritance from folders and groups, check them in a dedicated, replicated permission service with caching, handle revocation consistency, filter lists by reverse lookup or indexed access lists with a final check, and audit changes. For Slack-like products, add workspace roles (RBAC) and channel membership (ReBAC). See Design Slack.

Checklist

• Clear separation of authentication and authorization.
• RBAC for organisation roles, ReBAC for sharing and inheritance.
• A central permission service with a schema of rules.
• Fast checks: caching, flattened groups, batching.
• Consistency on revocation (snapshot tokens or synchronous invalidation).
• List filtering with a final per-item check.
• Enforcement in every service, plus audit logs.