An Introduction to Google Zanzibar and Relationship-Based Authorization Control

Authorization systems determine who can access what in software applications. Most organizations start with simple systems where users have basic roles like "admin" or "user," but these approaches often break down as applications become more complex and user bases grow. Google faced this same challenge across their product portfolio and developed Zanzibar, an authorization system that handles over 10 million permission checks per second across services like Gmail, Google Drive, and YouTube.

This guide explains Google Zanzibar's approach to authorization and the relationship-based access control (ReBAC) model that powers it. We'll also cover how you can implement similar systems in your own organization using open source tools like SpiceDB. Whether you're evaluating authorization strategies, implementing permissions for a new application, or looking to replace a system that's reached its limits, this resource will help you understand the concepts and make informed decisions.

What is Google Zanzibar?

Google Zanzibar is an authorization system that Google built to manage permissions across all their products and services. Think of it as the system that decides whether you can view a shared Google Doc, edit a file in Google Drive, or access a specific Google Cloud resource. Rather than each Google product implementing its own permission system, they all use Zanzibar as a shared service.

How Zanzibar Fits Into Google's Infrastructure

When you interact with any Google product, authorization decisions happen behind the scenes. If you try to open a Google Drive file, Google needs to quickly determine whether you have permission to view it. This might seem straightforward, but consider the complexity: you might have access because you own the file, because someone shared it directly with you, because you're a member of a group that has access, or because you have access to the folder containing the file.

Zanzibar handles these complex permission calculations for hundreds of Google services. It manages over 2 trillion access control lists and processes authorization requests from around the world while maintaining consistency. This means that if someone removes your access to a document, that change takes effect everywhere immediately.

The system maintains good performance: it responds to 95% of authorization checks in less than 10 milliseconds and maintains 99.999% uptime. These numbers matter because authorization checks happen in the critical path of user interactions. Slow permission decisions mean slow applications.

The Zanzibar Paper and Its Significance

In 2019, Google published a research paper titled "Zanzibar: Google's Consistent, Global Authorization System" at the USENIX Annual Technical Conference [1]. This was significant because Google rarely shares detailed information about their internal infrastructure, but they recognized that authorization is a challenge many organizations face as they grow.

The Zanzibar paper [1] describes not just how Zanzibar works, but why Google built it and what problems it solves. It has since become the foundational reference for modern authorization system design, inspiring many organizations to adopt similar approaches for their own applications.

Cross-Product Integration: A Key Innovation

One of Zanzibar's most useful features is its ability to enable authorization checks across different Google products. For example, when you're composing an email in Gmail and attach a link to a Google Drive document, Gmail can check whether your email recipients have access to that document. If they don't, Gmail can warn you and offer to grant them access.

This cross-product integration is only possible because all Google services use the same authorization system with consistent APIs and data models. For organizations building multiple applications or considering how different software systems should work together, this demonstrates the value of unified authorization infrastructure.

Why Google Built Zanzibar: The Authorization Challenge

To understand why Google invested in building Zanzibar, it helps to understand the problems that most organizations encounter as their software systems grow in complexity. Google's challenges were similar to what many companies face today, just at a much larger scale.

The Problem with Application-Specific Authorization

Most applications start with authorization logic built directly into the application code. This approach works well for simple systems, but creates problems as organizations grow. Each development team tends to implement their own authorization patterns, leading to inconsistent user experiences and duplicated effort.

Imagine you work at a company with separate applications for project management, document storage, and customer relationship management. Each system has its own way of managing permissions. In the project management tool, you might be a "project owner." In the document system, you're an "editor" on some files and a "viewer" on others. In the CRM, you have "regional access" to certain customer accounts. When these systems need to work together (perhaps showing project documents in the CRM), the different permission models create integration challenges.

At Google's scale, these problems multiply. With hundreds of services and billions of users, maintaining consistent security policies across isolated authorization systems becomes nearly impossible. Different teams implement different permission models, creating confusion for users and significant overhead for security teams who need to understand and monitor multiple systems.

Understanding the "New Enemy Problem"

One of the most serious issues that Zanzibar addresses is what Google calls the "new enemy problem." This is a security vulnerability that can occur when permission changes and content modifications aren't properly coordinated.

Here's a concrete example: Alice removes Bob from a document's permission list because he's no longer on the project. Immediately after removing his access, Alice adds sensitive information to the document. If the authorization system is using outdated permission data when checking Bob's access to the new content, Bob might be able to see information he should never have access to.

This timing-based vulnerability becomes particularly dangerous in distributed systems where network delays and caching can create windows of inconsistent state. The solution requires what's called "external consistency," which is a guarantee that authorization decisions respect the proper ordering of operations, even when those operations happen across different systems and geographic regions.

Google's solution involves sophisticated coordination between their authorization system and their globally distributed database infrastructure. While most organizations don't need Google's level of sophistication, understanding this problem helps explain why authorization systems need careful design around consistency and timing.

Scale and Performance Requirements

Google's authorization needs extend far beyond what traditional systems can handle. The system must support billions of users accessing trillions of objects, with permission relationships that can be deeply nested and constantly changing.

Consider a permission check that needs to determine whether a user can access a document. This might require checking:

• Whether the user was explicitly granted access
• Whether the user is a member of any groups that have access
• Whether the user has access to the folder containing the document
• Whether any of the user's groups have folder-level access
• Whether the user has inherited access through organizational hierarchy

Each of these checks might require looking up additional relationships, potentially creating complex queries that traverse many levels of the permission graph. The system needs to handle these complex queries while maintaining low latency, because authorization checks happen on every user interaction.

Traditional role-based access control (RBAC) systems struggle with this complexity, while policy-based systems can introduce too much computational overhead for real-time decision making at scale. These limitations led Google to develop relationship-based access control (ReBAC) and the architectural innovations that make Zanzibar possible.

Core Concepts and Architecture

Zanzibar's architecture is built around several key concepts that work together to provide fast, consistent authorization decisions at global scale. Understanding these concepts helps explain both how the system works and why certain design decisions were made.

Relationship Tuples: The Building Blocks

At the heart of Zanzibar is the concept of a "relationship tuple," which is a simple way to represent a relationship between objects and users. A relationship tuple has the format object#relation@user, which you can read as "user has relation to object."

Here are some examples:

• document:readme#owner@alice means Alice owns the document called "readme"
• folder:projects#viewer@bob means Bob can view the "projects" folder
• group:engineers#member@charlie means Charlie is a member of the "engineers" group

The power comes from combining these simple relationships to express complex permission scenarios. For example:

• document:readme#viewer@group:engineers#member means all members of the engineers group can view the readme document

This last example introduces the concept of "usersets." Instead of specifying a specific user, you can reference a group of users defined by another relationship. This enables group-based permissions without requiring explicit storage of every group member's access to every resource.

Relationship tuples can also express hierarchical relationships:

• document:readme#parent@folder:projects establishes that the readme document is in the projects folder

When combined with rules about how permissions are inherited (described below), this hierarchy enables automatic permission inheritance. If you have access to a folder, you might automatically have access to documents within that folder.

Namespace Configuration: Defining the Rules

While relationship tuples store the raw data about relationships, namespace configurations define how those relationships should be interpreted to make authorization decisions. Each type of object (like documents, folders, or groups) has a namespace configuration that specifies what relations are valid and how permissions should be computed.

For example, a document namespace might specify that:

• Anyone with "owner" permissions also has "editor" permissions
• Anyone with "editor" permissions also has "viewer" permissions
• Anyone with "viewer" permissions on the parent folder also has "viewer" permissions on the document

These rules are called "userset rewrite rules" and they're expressed using set operations like union, intersection, and exclusion. The beauty of this approach is that you can change permission policies by updating the namespace configuration without having to modify the stored relationship data.

Let's say your organization decides that editors should no longer automatically have full ownership rights. You can implement this policy change by updating the namespace configuration. All existing relationships remain the same, but the permission calculation changes immediately across all applications using the authorization system.

How Authorization Decisions Are Made

When an application needs to check whether a user has permission to perform an action, it sends a request to Zanzibar asking: "Does user X have permission Y on object Z?" Zanzibar then evaluates this request by:

1. Looking up the relevant relationship tuples
2. Applying the userset rewrite rules from the namespace configuration
3. Following any indirect relationships (like group memberships)
4. Returning a yes/no answer

For complex permission checks, this might involve multiple database lookups and rule evaluations. Zanzibar handles this efficiently through caching, parallel processing, and specialized indexing for complex scenarios like deeply nested group hierarchies.

Consistency and Performance Trade-offs

One of Zanzibar's key innovations is how it handles the trade-off between consistency and performance. The system uses "consistency tokens" called "zookies" that let applications specify how fresh the authorization data needs to be for each request.

For routine authorization checks, applications can accept slightly stale data in exchange for faster responses served from local caches. For critical operations that require the most recent permission data, applications can request stronger consistency guarantees, accepting higher latency in exchange for certainty that they're seeing the latest permissions.

This design reflects an important insight: not all authorization decisions require the same level of consistency. When you're loading a list of documents in your file browser, it's probably acceptable if the list takes a few seconds to reflect a permission change that just happened. But when you're trying to delete a document immediately after being granted delete permissions, you want the system to recognize your new permissions right away.

Relationship-Based Access Control (ReBAC) Explained

Relationship-Based Access Control (ReBAC) represents a different way of thinking about permissions compared to traditional authorization models. Instead of focusing on roles or policies, ReBAC models permissions as relationships between entities in a graph structure. This approach often feels more natural because it mirrors how we think about permissions in the real world.

How ReBAC Differs from Traditional Approaches

Most people are familiar with Role-Based Access Control (RBAC), where users are assigned roles like "Administrator" or "Editor," and each role comes with a predefined set of permissions. RBAC works well for hierarchical organizations with stable job functions, but it struggles with modern applications that need flexible sharing, fine-grained permissions, and complex organizational relationships.

Consider a document sharing scenario with RBAC. You might need roles like:

• Document Owner
• Department Editor
• Project Viewer
• External Collaborator
• Temporary Reviewer

As your organization grows and use cases become more complex, you end up with dozens or hundreds of very specific roles. This "role explosion" makes the system difficult to manage and understand.

Attribute-Based Access Control (ABAC) tries to solve this by making decisions based on attributes of users, resources, and context. While flexible, ABAC can become complex to manage and can have performance issues when evaluating complicated policies in real-time.

ReBAC takes a different approach by asking: "What relationship does this user have to this resource?" Instead of predefining roles or writing complex policies, you model the natural relationships in your domain and derive permissions from those relationships.

Real-World ReBAC Examples

Let's walk through how ReBAC works with a familiar example: a file sharing system like Google Drive.

When Alice creates a document, she automatically becomes its owner:

• document:budget_2024#owner@alice

Alice shares the document with Bob as an editor:

• document:budget_2024#editor@bob

Alice also grants viewing access to the Finance team:

• document:budget_2024#viewer@group:finance#member

Now when Bob tries to access the document, the system checks: "Is Bob related to this document in a way that grants access?" It finds the editor relationship and grants access.

When Carol from the Finance team tries to access the document, the system follows a longer path: Carol → member of Finance group → viewer of budget document. This indirect relationship grants Carol viewing access.

The power becomes apparent when dealing with hierarchies. If the budget document is in a "Financial Reports" folder, and the folder grants viewing access to the entire Accounting department, then members of Accounting automatically get access to the budget document through the folder relationship, even though they weren't explicitly granted access to the document itself.

Understanding Userset Rewrite Rules

Userset rewrite rules define how permissions are computed from stored relationships. These rules use set operations (union, intersection, exclusion) to express complex policies in a declarative way.

For a document, the "viewer" permission might be defined as:

• Union of: directly granted viewers + all editors (since editors can implicitly view) + viewers of the parent folder

This rule means that someone can view the document if they fall into any of these categories. The beauty is that this calculation happens automatically. When Bob becomes an editor, he automatically gets viewing rights without needing a separate viewer relationship.

More complex rules can handle sophisticated scenarios. A sensitive financial document might define viewers as:

• Intersection of: (Finance department members + Accounting department members) AND (Senior level employees + Temporary auditor access)

This rule requires both department membership and seniority level, with an exception for temporary auditors who might not meet the seniority requirement but need access for specific audit purposes.

When ReBAC Makes Sense

ReBAC is particularly valuable in scenarios involving:

Hierarchical Organizations: Companies with departments, teams, and sub-teams where access should automatically flow down organizational boundaries.

Collaborative Platforms: Applications where users create content and selectively share it with other users or groups, like document sharing, project management, or social platforms.

Multi-Tenant Systems: SaaS applications that need to model complex customer organizational structures while maintaining strict data isolation.

Dynamic Sharing: Scenarios where permission relationships change frequently based on project assignments, team memberships, or organizational changes.

The key insight is that ReBAC works best when your authorization requirements mirror natural relationships in your domain. If you find yourself creating many highly specific roles or writing complex policies to handle sharing scenarios, ReBAC might offer a simpler and more maintainable approach.

Enterprise Benefits and Use Cases

Organizations considering Zanzibar-style authorization systems often want to understand the practical benefits and whether the complexity is justified for their use case. The value becomes clear when you examine the common authorization challenges that enterprises face and how relationship-based systems address them.

Solving Common Enterprise Authorization Problems

Most growing organizations encounter similar authorization challenges. One of the most common is "role explosion," where RBAC systems accumulate hundreds of roles as teams try to model complex permission requirements. A typical enterprise might start with roles like "Manager" and "Employee" but end up with roles like "Regional Sales Manager with Customer Data Access" and "Temporary Project Collaborator with Limited Reporting Access."

This proliferation creates several problems:

• Administrative overhead increases dramatically as IT teams manage hundreds of role assignments
• Users struggle to understand what access they have or should have
• Security reviews become complex because it's difficult to understand what access each role actually provides
• Changes to business processes require creating new roles or modifying existing ones, slowing down business agility

Relationship-based systems address role explosion by modeling the underlying organizational structure directly. Instead of creating a role for "Regional Sales Manager," you model the fact that someone manages a region and separately model that managers have certain access rights. When organizational structure changes, the access rights automatically adjust without requiring role redefinition.

Another common problem is "privilege creep," where employees accumulate access rights over time without losing access from previous roles or projects. Studies suggest that the average enterprise employee has access to 17 million files [3], with many representing unnecessary or inappropriate access levels.

ReBAC systems can help address privilege creep through automatic access lifecycle management. When someone leaves a project team, their team-based access automatically terminates. When someone changes departments, their access automatically adjusts to reflect their new organizational relationships. This doesn't eliminate the need for access reviews, but it significantly reduces the scope and complexity of those reviews.

Quantifying the Business Impact

The business value of improved authorization systems extends beyond technical benefits. Organizations implementing centralized authorization report significant operational improvements:

Administrative Efficiency: Companies report reducing identity and access management workload by thousands of hours annually. This reduction comes from eliminating manual role management, streamlining access reviews, and automating permission inheritance through organizational structures.

Developer Productivity: When authorization becomes a service rather than something each application implements independently, development teams can focus on business logic rather than security infrastructure. Organizations report 30-50% faster development cycles for features requiring complex permission models.

Security Risk Reduction: With data breaches averaging $4.88 million in cost [2], improved authorization represents significant risk mitigation [4]. Centralized systems provide better visibility into access patterns, faster incident response, and reduced blast radius when security events occur.

Compliance Efficiency: Organizations with centralized authorization can generate comprehensive access reports across their entire application portfolio, reducing audit preparation time from weeks to days. The detailed audit trails inherent in relationship-based systems provide the granular access history required for regulatory compliance.

SpiceDB: Open Source Zanzibar Implementation

While Google's Zanzibar paper provides excellent documentation of the concepts and architecture, implementing a production-ready system from the paper alone would be a significant undertaking. SpiceDB, created by AuthZed, provides a mature open source implementation that brings Zanzibar's capabilities to organizations outside of Google.

What SpiceDB Provides

SpiceDB implements the core concepts from the Zanzibar paper [5] (relationship tuples, namespace configurations, userset rewrite rules, and consistency guarantees) while adding practical improvements learned from real-world deployments. The project has gained significant adoption across industries, with organizations ranging from startups to Fortune 500 companies using it for production authorization workloads.

The system maintains conceptual compatibility with Zanzibar while addressing practical challenges that arise when implementing such systems outside of Google's infrastructure.

Key Improvements Over the Original Zanzibar Design

While SpiceDB maintains fidelity to Zanzibar's core concepts, it includes several improvements that make it more practical for general use:

Multiple Database Support: Unlike Zanzibar, which is tightly coupled to Google's internal Spanner infrastructure, SpiceDB supports multiple database backends including PostgreSQL, CockroachDB, and Google Cloud Spanner. This flexibility allows organizations to leverage existing database investments while adopting ReBAC.

Human-Readable Schema Language: SpiceDB introduces a schema language that's much more accessible than Zanzibar's Protocol Buffer configuration format. Developers can express complex permission models in an intuitive format that supports version control, code review, and collaborative development practices.

Enhanced User Modeling: Where Zanzibar treats users as special terminal nodes, SpiceDB models users as objects within the relationship graph. This design enables more sophisticated scenarios like user hierarchies, delegation patterns, and complex identity system integration.

Improved Developer Experience: SpiceDB includes a comprehensive command-line interface with the zed CLI tool, interactive playground for learning and experimentation, and extensive documentation with practical examples. These tools significantly reduce the learning curve for teams adopting relationship-based authorization.

Understanding ZedTokens and Consistency

SpiceDB's ZedTokens provide equivalent functionality to Zanzibar's zookies while offering additional features for operational management. ZedTokens enable applications to specify consistency requirements on a per-request basis, balancing performance and correctness based on the specific needs of each authorization check.

For most authorization checks, applications can omit ZedTokens and receive fast responses based on cached data. For critical operations that require the most recent permission data, applications can provide ZedTokens that ensure the authorization decision reflects recent changes, accepting higher latency in exchange for stronger consistency guarantees.

This flexibility is crucial for real-world applications because different authorization checks have different consistency requirements. When loading a dashboard that shows what documents a user can access, slight staleness is usually acceptable. When checking whether a user can delete a document immediately after being granted delete permissions, strong consistency is essential.

Additional Resources and References

Essential Reading

• Annotated Zanzibar Paper - Comprehensive analysis with expert commentary from the creators of SpiceDB
• SpiceDB Documentation - Complete implementation guide and best practices
• Original USENIX Paper - The academic source that started it all

Hands-On Learning

• SpiceDB Playground - Interactive tutorial environment for learning ReBAC concepts
• GitHub Examples Repository - Sample implementations and integration patterns

Community

• AuthZed Blog - Latest insights, case studies, and technical deep dives
• Community Discord - Developer discussions, questions, and real-time community support
• SpiceDB on GitHub - Open source project with issues, discussions, and contributions

FAQs

What is Google Zanzibar?

Google Zanzibar is a globally distributed authorization system developed by Google to manage permissions across their services like Google Calendar, YouTube, Google Drive, Maps, Photos, and Cloud. It processes over 10 million queries per second while maintaining 99.999% availability and handling trillions of access control lists for billions of users worldwide.

How does Google Zanzibar work?

Zanzibar works by storing relationships between users and objects as "relation tuples" in a graph-like structure. When checking permissions (like "Can user X edit document Y?"), Zanzibar traverses these relationships using "userset rewrites" to determine if there's a valid path from the user to the required permission. It uses concepts like usersets and computed usersets to define complex permission rules efficiently.

What is Relationship-Based Access Control (ReBAC)?

ReBAC is an authorization model where permissions are derived from the existence of relationships between digital objects and users. Instead of assigning permissions directly, ReBAC models real-world relationships like ownership, membership, and hierarchies. For example, if Alice owns a document, and owners can edit documents, then Alice can edit the document through her ownership relationship.

Why did Google build Zanzibar instead of using existing solutions?

Google built Zanzibar to solve several critical challenges:

1. Scale: Supporting billions of users and trillions of objects
2. Consistency: Preventing the "new enemy problem" where authorization changes and content updates get out of sync
3. Cross-service authorization: Enabling services like Gmail to check permissions on Google Drive documents
4. Flexibility: Supporting diverse permission models from simple sharing to complex enterprise systems
5. Performance: Achieving low latency at global scale with sub-10ms response times

What is the "new enemy problem" that Zanzibar solves?

The "new enemy problem" occurs when authorization changes and content updates happen out of order, potentially granting access to users who should no longer have it. For example:

Example A: Alice removes Bob from a folder's permissions, then adds new documents to the folder. Bob shouldn't see the new documents, but might if the system uses stale permissions.

Example B: Alice removes Bob from a document, then adds new content. Bob shouldn't see the new content, but might if authorization checks use old permission data.

Zanzibar solves this with "zookies" that ensure authorization checks use appropriately fresh data.

What are zookies in Zanzibar?

Zookies are opaque consistency tokens that encode timestamps to ensure authorization checks use sufficiently fresh data. They prevent the "new enemy problem" by guaranteeing that permission checks reflect all relevant changes that occurred before content was modified. Applications store zookies with content versions and use them in subsequent authorization checks.

How does Zanzibar achieve high performance?

Zanzibar achieves high performance through several techniques:

1. Distributed caching: Results are cached across thousands of servers globally with consistent hashing
2. Request deduplication: Multiple identical requests are combined using lock tables
3. Specialized indexing: The Leopard system handles deeply nested group memberships efficiently
4. Request hedging: Slow requests are duplicated to faster servers
5. Geographic distribution: Data replicated globally across 30+ locations
6. Timestamp quantization: Coarse-grained timestamps enable better cache sharing

What's the difference between Zanzibar and traditional RBAC?

Traditional RBAC assigns roles to users and permissions to roles. Zanzibar's ReBAC model is more flexible:

• Traditional RBAC: User → Role → Permission (static assignments)
• Zanzibar ReBAC: User ↔ Object relationships that compute permissions dynamically

ReBAC can model RBAC (roles as objects with member relationships) plus complex scenarios like document sharing, organizational hierarchies, and resource inheritance that are difficult in traditional RBAC.

What is SpiceDB and how does it relate to Zanzibar?

SpiceDB is an open-source database for storing and querying fine-grained authorization data inspired by Google Zanzibar and created by AuthZed. Key differences from Google's internal system:

• Broader datastore support: Includes Spanner, Postgres, CockroachDB, and others
• User flexibility: Treats users as objects for more complex modeling
• Schema language: Provides a user-friendly schema language instead of protocol buffer configs
• Relations vs Permissions: Distinguishes between abstract relations and actionable permissions
• Additional APIs: Offers flattened lookup results and expanded functionality

What are the common use cases for Zanzibar-style authorization?

Common use cases include:

1. Document sharing: Collaborative editing with complex permission inheritance
2. Enterprise permissions: Organizational hierarchies and role-based access
3. Multi-tenant applications: Resource isolation between customers
4. Social platforms: Friend relationships and content sharing
5. Product-led growth: Frictionless sharing to drive user adoption
6. Fine-grained access control: Granular permissions for enterprise customers

How do I model permissions in SpiceDB?

Modeling involves defining:

1. Object types: Types of resources and subjects. Examples: Users, documents, folders, organizations
2. Relations: How two objects can relate to one another: Examples: Owner, editor, viewer, member, parent
3. Permissions: Access or abilities granted to sets of subjects. Examples: Create, delete, share

Example using SpiceDB schema:

definition user {}

definition document {
  relation owner: user
  relation editor: user
  relation viewer: user

  permission edit = owner + editor
  permission view = owner + editor + viewer
}

See SpiceDB docs for further guidance.

What are the performance characteristics of Zanzibar?

Based on Google's published metrics:

• Latency: 3ms median, 10ms 95th percentile for authorization checks
• Throughput: 10+ million queries per second
• Availability: 99.999% uptime over 3 years
• Scale: Over 2 trillion relation tuples across 1,500+ namespaces
• Global distribution: Serves requests from dozens of clusters worldwide

How does Zanzibar handle consistency at global scale?

Zanzibar ensures consistency through:

1. External consistency: Globally meaningful timestamps that respect causal ordering
2. Snapshot reads: Consistent view across multiple database reads
3. Zookie protocol: Ensures authorization checks use fresh enough data
4. Consistency semantics: Allows flexibility in choosing evaluation timestamps for performance

How does Zanzibar compare to policy engines?

Key differences:

• Zanzibar: Stateful service storing relationships, optimized for performance at scale
• Policy engines: Stateless engines where applications provide all data

Zanzibar is better for applications needing to store and query relationships efficiently, while policy engines are better for complex policy evaluation where relationships and data are managed elsewhere.

What industries benefit most from Zanzibar-style authorization?

Industries with complex sharing and permission requirements:

1. SaaS platforms: Document collaboration, project management tools
2. Enterprise software: Complex organizational permissions and hierarchies
3. Social media: Friend relationships and content sharing controls
4. Collaborative platforms: Team-based access with inheritance
5. Multi-tenant applications: Customer isolation and resource sharing

What are the key APIs in Zanzibar-style systems?

Core APIs include:

1. Check: Verify if a user has permission on a resource
2. Write: Add or remove relationships between objects
3. Read: Query existing relationships and group memberships
4. Expand: Get the full tree of permissions for a resource
5. Watch: Monitor changes to relationships over time

How does caching work in Zanzibar?

Zanzibar uses multi-level caching:

1. Distributed cache: Results cached across servers using consistent hashing
2. Request deduplication: Lock tables prevent duplicate computation
3. Intermediate result caching: Partial computations cached for reuse
4. Timestamp quantization: Coarse timestamps enable better cache sharing
5. Hot spot handling: Special caching for popular objects and groups

Read about how SpiceDB implements caching.

References

[1] Pang, R., Caceres, R., Burrows, M., Chen, Z., Dave, P., Germer, N., ... & Wang, M. (2019). Zanzibar: Google's consistent, global authorization system. In 2019 USENIX Annual Technical Conference (pp. 33-46). USENIX Association. https://research.google/pubs/zanzibar-googles-consistent-global-authorization-system/

[2] IBM Security. (2023). Cost of a Data Breach Report 2023. IBM Corporation. https://www.ibm.com/reports/data-breach

[3] Varonis. (2019). Global Data Risk Report 2019. Varonis Systems, Inc. https://info.varonis.com/hubfs/Varonis%202019%20Global%20Data%20Risk%20Report.pdf

[4] OWASP Foundation. (2021). OWASP Top 10 2021. https://owasp.org/Top10/A01_2021-Broken_Access_Control/

[5] AuthZed, Inc. (2025). SpiceDB Documentation. https://authzed.com/docs