Zanzibar is a distributed cache, and a request is served by making calls between servers and chasing pointers.
Take one query: is Adeeb a member of Zoom? One Zanzibar node may not be able to answer it, so it hops from one node to another:
- The members. One node stores who the members in Zoom are, and they are fetched.
- The concentric relation. Admins are by default members, as editors of a Google doc already have view access, so the admins are added.
- The tuple set. All the members and admins are fetched and checked for Adeeb.
To minimise RPC calls, the data is sharded by object ID. Zoom is the object and Adeeb is the user, so member, guest and admin in Zoom are kept in one shard.
The query now costs one call to reach the shard, plus zero for the admins, plus zero for the tuple set.
One user's permissions still hit multiple shards. The usual query asks whether a person has access to a document, so the access pattern matches the object ID.