Authorization is a critical component of any application, and we have made significant investments to ensure that Oso Cloud is a highly available system. We have redundancy built-in, and services deployed across regions worldwide. You can read more about our architecture in Our Unusual Journey to ECS on EC2 and Building a resilient and low-latency service using Kafka and SQLite. We also offer a 99.99% SLA for Oso Cloud.
However, no system is immune to unexpected failures. To build a truly robust solution, it is important to have short-circuiting mechanisms and backup plans in place. For teams that appreciate the convenience of a managed service, but still want to ensure they have an extra layer of safety, we offer a Hybrid Deployment model.
If you have Fallback deployed, if Oso Cloud encounters issues, such as:
- Returning 5xx errors
- Being unreachable
- Experiencing failed connections
Your app can continue to make authorization requests and get responses via the Fallback service. This ensures your app remains up and operational, even in the case of an unexpected Oso Cloud outage.
How It Works
The Oso Fallback Service fetches periodic snapshots of your data and acts as a backup if Oso Cloud is ever unreachable. All our Client SDKs support fallback. For example, here’s how you configure fallback with the Python SDK:
# Assumes Oso Fallback is hosted at http://localhost:8080
oso = Oso(url="https://cloud.osohq.com", api_key=YOUR_API_KEY, fallback_url="http://localhost:8080")Using Fallback Completely Offline
Fallback instances will continue to run even if Oso Cloud is unreachable. However, because they rely on the Oso Cloud Control Plane to download snapshots of your policy and facts, there are additional cases to consider:
- Oso Cloud Data Plane is down, Oso Cloud Control Plane is running → Fallback service is completely unaffected.
- Oso Cloud Data Plane is running, Oso Cloud Control Plane is down → Fallback service will not be used.
- Oso Cloud Data Plane is down, Oso Cloud Control Plane is down → Existing Fallback services will keep running with the last snapshot, but new ones cannot initialize their data.
While it’s unlikely that both the Oso Cloud Control Plane and the Oso Cloud Data Plane are down simultaneously, if you need to scale Fallback instances during such an event, you can use offline snapshots.
Offline snapshots allow you to export data when Oso Cloud is healthy and import it to start new Fallback nodes if Oso Cloud becomes completely unavailable.
Our goal is to make Authorization easy, so you don’t have to manage these complexities. However, we understand the realities of maintaining a production system and the importance of having backup plans to prepare for any scenario.
For details on what’s new with Fallback GA, check out our Changelog.
