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.

your APIs support asking for the data at a specific point in the past?

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.

you may not, but the system requires it for safety

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?

not all subsequent calls will be at "latest"