Question about zookies and consistency - what’s the practical risk of not using zookies at all? My understanding is that if no zookie is provided with a check request then cached relation data will be used if available - does that mean that, for an object that was just created, there’s a high likelihood that a check will fail? Consider this use case - I post to my feed and should be able to see it immediately on my feed. Do I need to use zookies to ensure this flow works?

there is the potential that could happen, yeah. I depends on various factors, hence if you are expecting read-your-own-writes consistency, use

AtLeastAsFresh

with ZedToken or check with

FullConsistency

Have you seen any patterns for easily implementing this? Feels like storing a new type of data across our microservice architecture is a non starter and so using FullConsistency is the answer - but to minimize the calls using that we’d have to read the createdAt time stamp of the object first and only use it if createdAt is within the last few seconds or so

it's an integral part of Zanzibar's design. Zanzibar is fundamentally a very clever cache for authorization, but in exchange it asks for cooperation to achieve strong consistency and scalability. Authorizing fresh data is inherently going to be more expensive because the chances that data was already cached are low, so even if you used ZedToken, it does not mean database reads will be completely avoided. For this specific scenario, and depending on your client application and setup, the difference between using

FullyConsistent

and

AtLeastAsFresh

may not that significant, but it sounds like the cost of asking different service to store a ZedToken would definitely offset that. If I understand that what you want to do is that after a X amount of time (presumably the quantization window you've configured SpiceDB with), you'd call

MinimizeLatency

, correct? In theory that would work, but as you probably know clocks in distributed systems can be a bit picky 😜 @Joey @jzelinskie do you guys have perhaps other ideas?

You could use a zedtoken store in something like redis

Honestly I’m not following that last paragraph at all - regarding MinimizeLatency etc.

So the SpiceDB API allows you to define the consistency you want in your requests: - minimize latency gives you the answer based on whatever is cached, with potential stale results, but within a maximum window called the "quantization window" - fully consistent is "do not use the cache at all, always query DB" - at_least_as_fresh is "I'm ok with certain bounded staleness", the result should not use cached results that are older than the point in time represented by the token

Ok I think I’m following you now. Thanks for the details. I think we’ll need to discuss this in greater depth on a call at some point. Given the many variables with caching, on top of the fact that a write is async - it’s not clear to me how we can guarantee that an owner can always view the thing they create, let alone friends of the owner etc.

putting SpiceDB aside for a moment, how does your architecture propagate changes? Are you using something like Kafka and services mantainers would be listening to the relevant events?

Exactly! Yes

Correct! If you're already eventually consistent because of using Kafka, it's honestly a matter of just how much each application can tolerate. You've probably already architected your services to tolerate some amount of eventual consistency.

yeah, you'd do a write and store its zedtoken if you wanted to provide "immediate" access to the user that was just granted access

>putting SpiceDB aside for a moment, how does your architecture propagate changes? Are you using something like Kafka and services mantainers would be listening to the relevant events? In case you wanted to continue doing async, I could imagine a flow like this: - Service A writes object and emits event (watch out, this is a dual-write, ideally you do Event Sourcing, so first emit event, and then write object based on event) - A "PermissionUpdaterService A" listens to event from ☝️ and writes the corresponding relationship(s) to SpiceDB. After that it emits an event like "PermissionChanged" with the ZedToken - Any service that needs to check for permissions for that object will use

FullyConsistent

, until the event with the

ZedToken

arrives, and then they use it with

AtLeastAsFresh

> but please note this is also a distributed transaction, which comes with its own challenges Technically, emitting a Kafka event from application code is also a distributed transaction, and unfortunately that's not typically solved for by application servers. But your warning is fair - we will weigh the risks!

you mean just emitting an event and not DB write + event?