1/ Let's continue exploring how the "Zanzibar" model allows us to solve #fgaatscale
3️⃣ Correctness: no invalid permissions are granted
To provide "correct" answers, an ACL check needs to always read a "valid view" of the system.
https://twitter.com/Auth0Lab/status/1334149962188382210?s=20👇
3️⃣ Correctness: no invalid permissions are granted
To provide "correct" answers, an ACL check needs to always read a "valid view" of the system.
2/ "Valid" means: the full state read from storage should have existed at a "logical point in time" and includes all committed records at that point.
The picture provides a counterexample, a request should not read two different values from a namespace at different reads.
The picture provides a counterexample, a request should not read two different values from a namespace at different reads.
3/ Similarly, new tuples should not "show up" in a request's query replies while it executes.
This applies to:
- in progress transactions
- records committed in the lifetime of the request
Summarizing: reads should be consistent at a "logical timestamp" within a request.
This applies to:
- in progress transactions
- records committed in the lifetime of the request
Summarizing: reads should be consistent at a "logical timestamp" within a request.
4/ Additionally, to avoid these issues:
Zanzibar implements:
- Configuration consistency: namespace configuration data is read at a single "logical time" for the entirety of each request.
https://twitter.com/Auth0Lab/status/1326240886674649093?s=20writes must maintain causal consistency.
Zanzibar implements:
- Configuration consistency: namespace configuration data is read at a single "logical time" for the entirety of each request.
5/ - Causal consistency and "logical timestamp" reads for tuples through Spanner's TrueTime mechanism (cloud.google.com/spanner/docs/t…)
6/ 4️⃣ Low latency
🌏 Zanzibar runs on multiple geographical regions, maximizing co-location with its clients. This both reduces latency as network RTT is minimized, and also increases the systems availability as issues in a single region do not affect the system's availability.
🌏 Zanzibar runs on multiple geographical regions, maximizing co-location with its clients. This both reduces latency as network RTT is minimized, and also increases the systems availability as issues in a single region do not affect the system's availability.
7/ It also:
- Has an internal indexing system to deal with queries that involve deeply nested group structures
- Uses "hedge requests" to minimize tail latency, i.e. sending requests to multiple servers and responding once the fastest one replies (www2.cs.duke.edu/courses/cps296…)
- Has an internal indexing system to deal with queries that involve deeply nested group structures
- Uses "hedge requests" to minimize tail latency, i.e. sending requests to multiple servers and responding once the fastest one replies (www2.cs.duke.edu/courses/cps296…)
8/ By storing namespaces configuration as part of the server, Zanzibar avoids the need for potentially slower distribution of logic and data to client side policy execution.
9/ 5️⃣ High availability
👩🚒 A consequence of its multi-region setup and write consistency model is that Zanzibar can tolerate more than one region failing and continue to work.
👩🚒 A consequence of its multi-region setup and write consistency model is that Zanzibar can tolerate more than one region failing and continue to work.
10/ 💪 Redundancy at the compute and storage level (through Spanner) exists in each region's Zanzibar cluster, to tolerate issues with single instances.
---
In the upcoming weeks we'll be sharing more about our decisions implementing a Zanzibar inspired system as a SaaS.
---
In the upcoming weeks we'll be sharing more about our decisions implementing a Zanzibar inspired system as a SaaS.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
