Will cache be in-sync in all instances? Or do i have to use ZedToken for all check calls?

if you do not use a ZedToken for any calls, then best effort caching will be used (there is no need to sync the caches). It is recommended to use a ZedToken IF you are immediately reading after writing, or you have concerns about New Enemy

generally, we recommend using a ZedToken because it ensures safety while also making use of caching where reasonably possible

Yes, we will use ZedToken. But want to know the worst case when we dont have zed token

if you don't have a zed token, you have two options

(1) call with

full_consistency

, which will bypass most caching, but is guaranteed to be safe (but slow at times)

(2) call with the default options, which means your

Check

call might be slightly out of date due to hitting a cache; it should be no more than a few seconds

the general recommendation is: call with

full_consistency

if you don't have a ZedToken (such as the initial call), and then store a ZedToken for all subsequent calls

Yes ZedToken seems to be the only way, we wanted to avoid that as just to save that we have to run a redis instance.

yeah, even if the caches did sync, you'd still need the ZedToken to ensure the correct version of the cache was used

Yes, but running multiple spicedb instances with ZedToken will have more cache miss ratio. We need someway to update cache in all instances

not if you use the redispatch system

then it would dispatch to the same SpiceDB node for the same incoming request

for example, if you use Authzed.com, and you issue two calls of the same Check, one after another

they'll be routed to the same SpiceDB node

that way, the cache is used for the second call

(its a bit more complicated than that, but that's the general overview)

Can we do this with kube cluster? As we will depend on kube for the load balancing and routing inside cluster

yes

we do it under Kub

we'll be adding some documentation soon about how to configure it

Can you share some template yaml for deployment?

We want to test the multiple spicedb setup

Unfortunately, our deployments are really coupled to our infrastructure. We use another service internally that actually does the peer discovery and it isn't open source (yet?). Our deployment is trying to be super sensitive to avoiding any possible latency degradations during any scaling/deployment/upgrade. In the mean time, we'd be open to a contribution that adds something more generic for others to use that wouldn't require running another service.

I don't want Spice to enforce the "exactly one"-relationship (or any relationship for that matter). I was just setting the scene 🙂 I like your simplification, however products will not always belong to a 'department', sometimes only to an organization, so that'd not necessarily work, however your example definitely inspired me. For now we've talked about specific products, but how about listing products as a whole? Is there some sort of convention for that? Since there's no specific ID. I know that there's no specific definition for the 'id' part to be an actual ID, so would I just choose a convention for constructing arbitrary ids which are guaranteed not to collide? Would I make a definition for a 'product list' entity? Would I reverse that and put it as a permission on the organization (i.e. "does John have permission list_products on organization Y" ? Is there an actual 'best practice' way or is it completely up to the queries how I define it? Example:

product:dep_depId#department@department:depId
product_list:depId#department@department:depId

Hi folks, how could I deploy isolated environments of SpiceDB for temporary testing environments? In the company I work for we try to provide isolated environments every time someone opens a GitHub PR. Ideally, any change only applies to their version of the app. I want to be able to create different SpiceDB instance on each PR. That seems possible by adding a SpiceDB instance to each k8s namespace for each of temp environments. Schema changes would only apply to that instance. Where I'm stuck is how can I feed existing relationship data to this recently created instance? Is there a way I can copy relationships from another SpiceDB instance? We often have a Staging environment of each application with test data. We start PR env dbs by loading a backup of this staging environment. Would that work if we use the Postgres backend for SpiceDB?

@User are these SpiceDBs fully ephemeral?

Yeah, we will destroy them when the PR is merged.

but they will need to be long-running during that time?

or only used for testing?