Concepts
Relationship-based authorization (Zanzibar)
Intuition
Imagine that, instead of keeping a list of who can open each document, you write down only simple facts: "Ana is a member of this team", "this team has access to this folder", "this document is inside this folder". To find out whether Ana can open the document, you just follow the chain of facts until you find a path that links Ana to the document. This way, when a fact changes (Ana leaves the team), everything that depended on it changes with it, without having to rewrite any list.
How it works
In Zanzibar, permissions are stored as relation tuples in the format object#relation@user; groups are not a special entity, but objects whose relations represent membership. The user side of the tuple can be a userset, that is, the set of those who have a certain relation to another object, which makes it possible to represent nested groups. Each namespace (object type) has a configuration with userset rewrite rules, which derive one relation from others without writing redundant tuples: it can come directly from the tuples, be inherited from another relation on the same object (whoever is an editor also counts as a reader), or be obtained by following a parent object (inheriting the readers of the folder that contains the document). This way, the complex policy lives in the configuration and the storage keeps only simple facts; the API includes Read, Write, Check, Expand and Watch, and Check answers whether a user has a given relation to an object. The tuples live in Spanner, whose commit timestamps reflect the causal order of writes; to avoid the new enemy problem (for example, still seeing a sensitive document after being removed from the folder's ACL), the client receives a zookie when it authorizes a content change, stores it along with that version, and sends it on subsequent checks, which are then evaluated on a snapshot at least as recent as the zookie. Without a zookie, the system picks a recent snapshot that favors low latency, so the freshness cost is paid only where causal guarantees are needed. For very large, deeply nested groups, where walking the hierarchy would be slow, the Leopard indexing system represents group membership as sets and speeds up reachability queries; against hot spots, the servers use a distributed cache with consistent hashing and a lock table so that several requests do not compute the same result at the same time.
In practice
The paper became the reference for relationship-based access control (ReBAC), in which the decision depends on the relations between entities and not just on fixed roles; it makes sense to consider it for products with sharing, folder inheritance, and nested groups, where permission is in practice a graph of relations. According to the paper, Zanzibar serves hundreds of Google services and, over more than three years in production, kept 95th-percentile latency below 10 ms and availability above 99.999%. The design lesson is to separate a minimal tuple model, a declarative configuration that derives permissions, and a central service that treats causal consistency, caching, and tail latency as requirements from the start, handing the zookie to the client instead of forcing always-fresh reads.
Use it in a design
Practice the cases that rely on this concept in the System Design school.