Zanzibar authorisation system by Google

Imagine you are building a new application. At first, everything is simple because you only have a few users and a basic role system. But then Google Drive, YouTube and Calendar come along, where billions of people share billions of resources with each other in real time. How do you manage such a mass of permissions so that the system doesn't collapse under its own weight and, more importantly, so that no one sees something they lost access to a second earlier? Google's answer is Zanzibar, a system with a very interesting architecture.

Dot-based data model

The traditional approach to permissions is often based on ACLs (Access Control Lists) attached directly to objects. Zanzibar reverses this paradigm and treats permissions as a global set of relationships stored in the form of dots. Each dot is a connector: an object, a relationship, and a user. Thanks to this, the system does not have to search the metadata of each file separately, but operates on a unified database of facts about the relationships between entities.

In Ruby, we could model such a tuple in a very simplified way to understand its structure.

# This class represents a simple Zanzibar-style relation
class RelationTuple
  attr_reader :namespace, :object_id, :relation, :user_id

  def initialize(namespace, object_id, relation, user_id)
    @namespace = namespace    # e.g., "doc" or "folder" or "group"
    @object_id = object_id    # the unique identifier of the resource
    @relation = relation      # the role, e.g., "viewer" or "editor"
    @user_id = user_id        # the identity of the user or a group
  end

  # Returns a string representation of the tuple
  def to_s
    "#{@namespace}:#{@object_id}##{@relation}@#{@user_id}"
  end
end

# Creating a new permission where "user_99" is an "editor" of "doc_alpha"
new_permission = RelationTuple.new("doc", "doc_alpha", "editor", "user_99")
puts "Stored permission: #{new_permission}"

In the code description, RelationTuple serves as a container for access definitions. However, the real power lies in the fact that user_id does not have to be a person - it can be another group, which allows for the creation of nested structures. In an SQL database, such records would look extremely simple, which is conducive to efficient indexing.

CREATE TABLE relation_tuples (
    namespace VARCHAR(255) NOT NULL,
    object_id VARCHAR(255) NOT NULL,
    relation VARCHAR(255) NOT NULL,
    user_id VARCHAR(255) NOT NULL,
    PRIMARY KEY (namespace, object_id, relation, user_id)
);

-- Adding a viewer to a specific folder
INSERT INTO relation_tuples (namespace, object_id, relation, user_id)
VALUES ('folder', 'finance_2025', 'viewer', 'user_456');

At its most basic level, Zanzibar is simply a huge, standardised table. The magic begins when we need to check permissions in a distributed environment.

The problem of the new enemy and data consistency

The biggest challenge in distributed systems is not performance itself, but consistency. Google defines this as the ‘New Enemy’ problem. Imagine that you remove a former employee from access to a folder containing confidential data. A moment later, you add a new file to that folder. If the authorisation system in another data centre has not had time to update, that employee could theoretically see the new content. Zanzibar solves this with the help of the Google Spanner database and the TrueTime protocol.

Each permission change receives a precise timestamp. When an application checks access, it can request a check with a specific freshness level. This ensures that if the access removal operation was completed before the new content was created, the authorisation system is definitely aware of it. This approach eliminates security gaps resulting from delays in data replication between continents.

Optimisation with the Leopard system

Checking permissions in deep structures (e.g., whether a user belongs to a group that belongs to another group that has access to a folder) can be deadly for performance. Zanzibar solves this with the Leopard subsystem. It is a layer that denormalises permission graphs and stores them in memory as optimised lists.

Instead of performing dozens of recursive queries, Leopard allows group membership to be checked in almost constant time. It uses set operations to do this, which, with millions of queries per second, is the only way to keep latency in the millisecond range. For us as engineers, the lesson is clear - sometimes the best way to achieve fast read times is through intelligent redundancy and preparing data in a form that is ready for immediate response, rather than calculating everything on the fly.

Zanzibar proves that at the right scale, even a simple task like checking ‘can he see this’ becomes a fascinating engineering challenge. While most of us don't build systems for billions of users, the principles of standardising the data model and ensuring external consistency are universal in any modern architecture.

Happy zanzibar-ing!