White paper: Zanzibar: Google's Consistent, Global Authorization System

The conversation opens with an admission the participants repeat several times: while there is one application, authorization is simple, and the complexity grows with the number of teams and the distribution of the system. Ilya walks through the evolution of models — from access lists and a subject-by-object matrix that is inefficient to store in full, to roles and then to attributes. Sergey Klimenko, ten years at T-Bank and five of them leading authentication and authorization, describes where the role model broke in the product for small and medium business: roles had to be granted temporarily, say to an accountant for a limited period, and there turned out to be too many resource types — organizations, applications, groups of companies — for tidy roles. Alexander adds that RBAC is clear to management right up to the moment granularity is needed, and then the team starts bolting access lists onto roles.

The attribute model removes the user-to-role link but brings its own price: policies are written by dedicated people, cognitive complexity rises, audit becomes mandatory because a policy mistake takes down the whole system, and evaluating complex policies slows down. The discussion then reaches the architectural knot that produces such systems in the first place: once a monolith turns into a distributed system with front ends and service-to-service calls, there is a choice between decentralization and centralization. Token-based decentralization runs into token size and the impossibility of revoking a right quickly; centralization on a shared database is a bad but real pattern. What is needed is a single point that answers the question "may I perform this action" — and Zanzibar appears exactly at that boundary.

Google's model is described through object–relation–subject tuples, where the subject can be either a user or the user set of another object. The tuples form a graph, and an access check becomes a path search in it. The participants like the compactness: the grammar of relations is explicit, tuples read as text, and the whole paper fits into roughly fifteen pages. Ilya shows a schema from SpiceDB — an implementation by ex-Googlers: a document is linked to an organization, view permission is inherited by owners, readers, and the organization's admins, and the schema is stored separately from the relations, so the access model changes by editing the schema without rewriting relations — with the caveat that migrations on a schema change still have to be thought through. The paper's five goals are spelled out — correctness, flexibility, low latency, high availability, and scalability — along with the result: a median of about three milliseconds and twenty at the ninety-ninth percentile under millions of checks per second.

The most contested part is the "new enemy" problem: if Alice removed Bob from a folder and a new document was then placed in it, Bob must not see the document, but will if the check ignores the order of changes. Google solves this with timestamped snapshots and a zookie — a token the client receives when writing a relation and must send with subsequent checks. Daniil explains the mechanics: a server with a stale cache will not answer with old data but will look for a fresher snapshot on other nodes and, as a last resort, in storage — reading from storage increases latency compared with reading from the cache. It is a deliberate choice of correctness over response time, and Zanzibar lets you apply it not to every namespace but only where the cost of a mistake is high. Alexander recalls the criticism: the zookie has to be stored on the client side and updated consistently with the write, which is why people say applications are built around Zanzibar rather than Zanzibar being embedded into applications, shipping their object and group data into it.

The participants then take apart the optimizations. The Leopard index flattens deeply nested groups so that the graph is not traversed on every request; its updates arrive through a Watch server that tracks changes to schemas and relations. The long tail is fought with hedging: a request first goes to one node and is only duplicated to others if no answer arrives within a threshold like one hundred milliseconds, and the threshold itself adapts to the observed tails. The cost of every call is measured in CPU-seconds, clients have global limits plus caps on pending requests and concurrent reads per object, and the lock table uses different keys for different clients — Alexander calls this built-in multitenancy without the noisy-neighbour effect that systems written on the assumption that all clients are well-behaved sorely lack. Caches sit on both sides, and the lock table prevents the same heavy request from being computed in parallel; Ilya recalls a similar layer Twitter had described.

The open question is lists: showing a hundred objects with five permissions each naively means five hundred checks, and on hundreds of thousands of objects, permission-aware search becomes a problem of its own — the participants mention batch checks on SpiceDB's roadmap and an index the community calls Tiger. The finale is about T-Bank's own plans. Sergey explains why the team moved away from Open Policy Agent: its policy language takes time to learn, and the data does not fit into a sidecar once there are millions of clients; and why it did not stay with roles — the granularity of requirements only grows. The new authorization system will be built on SpiceDB, written in Go, with the understanding that it will need filing down and namespace tuning. Alexander sums up: Google's white papers set the concepts around which open tooling later grows, and following that is a way not to collect every rake yourself.