Oso Cloud Architecture

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

Architecture of Oso Cloud: Events stream to Oso Cloud Edge Nodes, and your apps send redundant requests to Edge Nodes in multiple Availability Zones

Oso Cloud deploys nodes at the edge, across dozens of regions and availability zones all over the world. It uses event sourcing for replication: a primary message broker streams updates to Edge Nodes, keeping them in sync with your fact and policy data.

High availability

Oso Cloud has no single point of failure. We spread Edge Nodes across regions and availability zones to protect against network failures in any particular data center and to insulate your app from any one node's downtime, providing high availability. Oso Cloud has already withstood multiple region-wide outages without any customer-visible impact.

We provide SLAs on availability. The chart below shows our measured production availability over the calendar year from Jan 30th, 2024 to Jan 29th, 2025.

Datadog report that shows the last year availability across many regions, 99.99% and up

The test that's running in each region, every minute with three assertions, is as follows:

Availability test across 12 locations every minute with 3 assertions.

You can optionally deploy Oso Fallback Nodes colocated with your application inside your VPC. These run a current version of the Oso Cloud API and contain a copy of your rules and data to provide an extra layer of insurance you can always use to make authorization checks, even if Oso Cloud is unreachable. Fallback Nodes may lag Edge Nodes by up to 30 minutes. They are for disaster scenarios only and are not intended to be a primary server for running authorization requests.

If you'd like more information, you can meet with an engineer (opens in a new tab).

Performance

Oso Cloud optimizes for low latency (<10 ms end-to-end) in two key ways.

First, we deploy Edge Nodes in your regions, which keeps network latency low (2-5ms). Second, Edge Nodes precompute indexes and cache queries, keeping in-process response times low for most requests (<2 ms).

Edge Nodes scale dynamically to handle high request volumes. Our system auto-scales to match your throughput needs, ensuring consistent performance.

Oso Cloud Edge Nodes run in AWS within Oso's own VPCs. While we operate in most AWS regions, we can deploy nodes in a new region within minutes.

We offer dedicated Edge Nodes deployed in your region and understand that authorization performance is a complex topic. Meet with an engineer (opens in a new tab) to discuss custom deployments and explore the best approach for your use case.

Next Steps

Now that you have learned how Oso Cloud guarantees reliability with high availability, low latency, and high throughput, you can:

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 →