Hi! What do you guys recommend for handling storing ZedTokens? I checked a few articles about consistency in the blog and documentation, but some questions remain open to me. 1. How to handle storing zed tokens? I saw 3 different options, but the most scalable solution is streaming commits. While SpiceDB provides an example how to handle zed tokens in 2PC option, it's unclear what's the suggestion to update zed tokens using streaming commits, when committing new business data happen within one process, but update relationships in SpiceDB might happen in the second process. In this case, I don't see any other option but to make a second request to the database to update zed token received after writing relationship to SpiceDB. This sounds a bit overhead 2. What does mean content changed? It's probably the simplest question, but I want to make sure that it means whenever the column value of some record changes it must cause an updating zed token in respective record. 3. For what endpoints do we consider using different consistency strategies? Article about consistency explains a lot about the necessity of having strong consistency, and I understood that strong consistency must be provided in place where there is no tolerance for stale permissions. But what I didn't understand from article, does

at_least_as_freash

provides the same consistency as full consistency option if I'm sure that zed token is the most updated. So, let's say I want to have strong consistency on delete endpoint and there is no tolerance for staleness, can I use zed token there or I must use full consistency option in any way? 4. Is it really a more performant way of using zed token, since I have to retrieve zed token first from my database? This is actually quite interesting to me, cuz it seems like bottleneck are moving from SpiceDB to application. Where I can check (or briefly explained) why making request to database is more performant rather using full consistency? Thanks!

1. what you're describing is how i'd approach it 1. it'd be whatever would be meaningful from the new enemy perspective. if it's a document, it'd be the body of the document (this is what you wouldn't want a user to see); if it's the details of a business object, it'd be whatever's considered sensitive. if you don't want to add the complexity of delineating what is and isn't sensitive, then yeah, getting a new zedtoken each time you update something on the record is a good starting place. 1. > does

at_least_as_fresh

provides the same consistency as full consistency option if I'm sure that zed token is the most updated yes, but that isn't the way i'd think about using

at_least_as_fresh

. it's meant as a way to provide a balance between performance and consistency for reads. i'd personally recommend using

fully_consistent

for deletes because it's a simpler model - you don't care whether the stored zedtoken is the most recent because you're saying "i want the most recent view of the system." 1. because you're already going to need to go to your DB to get your record. it won't meaningfully add to the request latency if you're just reversing the order of spicedb + db calls. it may require rethinking the flow of your request, especially if you were planning on doing authz in middleware, but you can still get the row in one middleware, do the authz in another middleware, and then do request handling logic inside the request handler, for example.

thanks for your reply!

sure thing!