Which consistency level should a SpiceDB client request after a relationship write?
0 reputation · 09 Aug 2024, 08:43 UTC
SpiceDB's stable authzed.api.v1 API, introduced with the 1.0 release, lets each permission call carry a consistency requirement: minimize_latency, at_least_as_fresh with a ZedToken, or fully_consistent. The documentation explains the trade-offs, but it does not prescribe which requirement a client should persist for a read-after-write flow.
The goal is to settle on one policy for a backend that writes relationships (for example, granting a role) and then immediately re-renders the permissions it just changed. The constraints: a check must never miss a write the same user just performed, fully_consistent is understood to be the costliest option because it cannot rely on cached dispatch results, and ZedTokens are opaque, so the client cannot tell how stale a stored token actually is. Assume a current SpiceDB 1.x server with a matching Go SDK; exact minor versions and any recent API changes should be verified against the release notes before relying on the behavior described here.
Which requirement best fits this flow: at_least_as_fresh with a token captured from the write response, or fully_consistent despite the cost? Is minimize_latency ever safe for read-after-write, or only for staleness-tolerant views? And when a request omits the consistency field entirely, which default does the server apply?