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.
We provide SLAs on availability. Meet with an engineer (opens in a new tab) to learn more about our SLAs.
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.
We offer dedicated replicas deployed in your region. Meet with an engineer (opens in a new tab) to talk more about custom deployments.
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 can provide SLAs for consistency lag. Meet with an engineer (opens in a new tab) to learn more about pricing.
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.
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.