Hey guys! 🙂 Is using the
# spicedb
t
Hey guys! 🙂 Is using the WatchServiceClient to store the ZedTokens in memory every time there is an mutation a good idea? Then use the stored ZedToken in the next check permission request
v
👋 hi, perhaps the first question would be what are you trying to achieve? You can technically do that, but it's not going to be great performance wise, you'd get a bad cache-hit rate because each time you do a check, there is nothing in the cache, because you always ask for the latest state of the system. It would be pretty much like doing
fully-consistency
all the time.
t
What I would like to achieve is using
at_least_as_fresh
with a zedtoken. However it didn't occur to me that the
changes_through
in the watch response has zedtoken but this token is not the product of performing a check request (where the response is cached), so that's why using the ZedToken from the watch response is probably going to like
fully-consistency
as you said?
I'm trying to understand consistency and how to ensure using cache but without use stale data, so I'm sure I've said something wrong
v
Yeah, what you get via the
Watch
response is the product of some mutation in the database side, mainly changes to the relationships stored (there is also support for changes to the schema but its not yet exposed via the API)
So the way to do this is to store the
ZedToken
returned by
WriteRelationships
next to the resource that was mutated in your main database, so that the next time you go and read it, you can pick up the ZedToken
and w.r.t to consistency:
AtLeastAsFresh
may give you stale data. The original paper refers to "bounded staleness", meaning that it may be stale data, but never data that compromises the security of your application (It guarantees it solves the so called "New Enemy Problem")
giving you stale data that is still secure is one of the key design choices to make Zanzibar/SpiceDB scale
t
Thanks a lot for your response. That was very useful 🙂
10 Views