https://authzed.com logo
#spicedb
I suspect it's not ideal for systems
# spicedb
p

pax0s3

01/14/2024, 4:43 AM
I suspect it's not ideal for systems with distributed state but in our case everything is using the same postgres database running in the same vpc as other services. I think we satisfy (1) today with a bunch of crud apps and (2) could be parallelized, or you could use hedging to amortize tail latency out of the batch.
j

Joey

01/14/2024, 4:47 AM
your APIs support asking for the data at a specific point in the past?
p

pax0s3

01/14/2024, 4:55 AM
Rather, I think we don't have to worry about drift since we have a single read/writer and resolving relations on read (vs writing ahead of time) wouldn't be an issue for us.
j

Joey

01/14/2024, 4:57 AM
you may not, but the system requires it for safety
p

pax0s3

01/14/2024, 5:07 AM
I guess I'm having trouble seeing how realizing the relation at read time is an issue? As a primitive example: 1.
select owner_id from repos where id=$repo_id
-> triple 2. Call
WriteRelationships(repo:repoid, owner, user:owner_id)
-> respond to user waiting on response with allow/deny + zookie 3. Subsequent CheckPermissions calls are good?
j

Joey

01/14/2024, 5:12 AM
not all subsequent calls will be at "latest"
the caching system will request earlier points in time
and if the system returns different results, it breaks the API