Concepts
Consistency

Consistency

As a rule, you can expect to read your writes.

Oso is eventually consistent by default, but in practice any lag under 100 ms is imperceptible for most applications due to the speed with which nodes replicate between each other. For cases where you need strong consistency guarantees, you can use Consistency Tokens.

Eventual Consistency - The Default

Oso Cloud is eventually consistent by default. While you can typically expect to read your writes, this default configuration can lead to reading stale data if either you attempt to read back a new or updated record synchronously with its write or if there is unusually high lag due to network issues (or both).

Oso Cloud is a distributed system optimized for high availability – i.e., optimized for ensuring that you can always make authorization checks and get a authorization response. When your app performs a write, like inserting a fact, deleting a fact, or updating your policy, the write is sent to an Oso Cloud primary message broker, which forwards the update to all of the Edge Nodes. The Check API will always continue to work, even if not all writes have propagated to every Edge Node. If a severe network problem has cut off your region from the rest of the world, Edge Nodes in that region will continue to respond properly to authorizations. Oso Cloud writes are therefore eventually consistent.

In practice, however, this does not impact most applications. While it is hypothetically possible that a newly created fact or recently updated policy may not be used during an authorization check, in practice the median replication lag is in the low hundreds of milliseconds. In the worst case, Edge Nodes won't fall out of sync by more than 1 second. And since Oso Cloud waits for the data to get replicated before returning a response, as long as your app waits for the response before reading, it will get a consistent result.

Strong Consistency with Consistency Tokens

Some applications require strong consistency guarantees, and for these use cases, you can use Consistency Tokens. Consistency tokens allow you to opt into a strong consistency model. While in most cases there is little downside to this approach, in some cases you may experience higher write latency (while Oso waits to commit the write to all nodes before responding).

Constency Tokens are currently in beta. Reach out if you're interested in trying them out: