Architecture of Oso Cloud

Oso Cloud is a managed authorization service, meaning that you can use it without much regard to how it works internally. That said, it can be useful to understand how Oso Cloud works under the hood — perhaps you want to gain confidence about Oso Cloud’s reliability guarantees, or perhaps you’re just curious.

We built Oso Cloud to run on the critical path for any application. Its architecture is designed to provide:

• High availability: the uptime of your app depends on the uptime of its authorization system. It cannot ever go down.
• Low latency: every request through your app needs to perform at least one authorization check (sometimes multiple). It needs to be fast.
• High throughput: an authorization service needs to scale with the number of actions that your users perform in your app.

How It Works

Oso Cloud uses Event Sourcing for replication: a primary message broker streams updates to read replicas, keeping them in sync with your fact and policy data. We deploy replicas globally: you pick a region (or multiple), and route authorization requests to replicas in that region. Oso Cloud replicas live in AWS, inside of Oso’s own VPCs.

Oso Cloud spreads replicas across availability zones to protect against network failures in any particular zone and to insulate your app from any one replica’s downtime, providing high availability.

It’s straightforward for us to launch replicas in new regions and availability zones wherever you have servers running. By deploying replicas in your region, we keep network latency as low as 2-5ms.

On average, each replica can serve ~10k requests per second. We deploy additional replicas as needed, depending on your desired throughput. This means there’s no upper bound on your read throughput.

Eventual Consistency

Oso Cloud is a distributed system optimized for high availability. 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 replicas. Oso Cloud writes are therefore eventually consistent.

The Check API will always continue to work, even if not all writes have propagated to every replica. If a severe network problem has cut off your region from the rest of the world, replicas in that region will continue to respond properly to authorizations.

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, replicas 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.

We are considering adding support for opt-in consistency mechanism to allow your applications to guarantee that a read occur after some write has been propagated. If you’re interested in this feature, let us know by filling out the form below.

Next Steps

• Learn more about the Oso Cloud data model and how it fits into your system.

Talk to an Oso Engineer

If you want to learn more about how to model your authorization with Oso Cloud or have any questions, connect with us on Slack. We're happy to help.

Get started with Oso Cloud →