Zanzibar's architecture is caches, backups and subscribers around one database, Spanner.
Clients send requests to the Zanzibar servers. These are access control list servers that expand, write and read, and they work as an in-memory cache of access control. Their database is Spanner.
Three things run behind the servers:
- A data pipeline picks up events from Spanner, and a batch job makes snapshots. A snapshot is a copy of the database taken every hour, so a failure still leaves a backup.
- An indexing system, called Leopard, caches the sets that are commonly queried, whether deeply nested or large. It reads the snapshots, so indexing does not affect the production database.
- A watch service streams the changelog to clients that subscribe to events. Leopard subscribes too, and changes its index as data is updated.
An index built on snapshots is acceptable because many requests carry no zookie. Zanzibar gives them the data it believes is fresh enough. A caller who wants the latest data sends a zookie.