Availability
As a business implementing Schematic, we understand you are trusting the solution to be highly available and reliable. Given the nature of the transactions that Schematic supports for businesses, we’re committed to both.
Your application connects to Schematic using our SDKs to share context about companies and users, and to retrieve flags values based on policies set up in Schematic. Our SDKs are here. If you need support for an SDK that is not listed, please let us know.
High Availability Strategies
Schematic is designed to be safe, fast, and reliable by default. Flag checks sit directly in the critical path of your application, so we treat availability and performance as first-order concerns.
Out of the box, Schematic is built to:
- Serve flag checks from cache, not live computation
- Preemptively warm and maintain those caches
- Remain operational through most classes of service disruptions
- Fail gracefully when parts of the system are unavailable
For most teams, these guarantees are enough. But some applications require even stronger assurances around freshness, latency, or independence from external services.
This guide outlines the three main ways you can run Schematic in a highly available configuration, ranging from fully managed to fully self-hosted.
1. Built-in High Availability (Default)
By default, Schematic is designed so that flag checks are always served from cache. This ensures they are:
- Fast - no expensive recomputation on read
- Reliable - resilient to most backend disruptions
- Predictable - consistent latency under load
Flag values are also preemptively cached, meaning they are warmed ahead of time rather than computed on first access. This avoids cold-start behavior and helps ensure that even the first request is fast.
In the event of most service disruptions:
- Flag checks will continue to function
- Values may become temporarily stale
- Normal operation resumes automatically once service is restored
This model prioritizes simplicity and operational safety. If your application can tolerate brief periods of staleness, this is typically the best option—and requires no additional configuration.
2. Replicator (Fully Local, Always Fresh)
For teams that need stronger guarantees around freshness, latency, and fault tolerance, Schematic provides Replicator.
Replicator maintains a fully up-to-date local copy of your flag data inside your own infrastructure. Your application reads directly from this local store, removing Schematic’s API from the critical path.
Benefits
Replicator provides three key benefits:
- Lower latency - Flag checks do not require external API calls.
- Always warm data - Updates are pushed in real time, so the first read is fast.
- Full incident resilience - If Schematic experiences an interruption, your application continues operating using your complete local cache.
This is the strongest availability and performance model we offer.
Availability
Replicator is available for Enterprise customers.
How it works
To use Replicator, you will:
- Host a Schematic-provided container in your infrastructure.
- Provide a compatible local data store (e.g. Redis).
That’s it. The Replicator container handles:
- Synchronization with Schematic
- Real-time updates
- Persistence into your local store
- Retry and reconnect behavior
3. SDK Fallbacks (Simple Offline Resilience)
For teams that want a simple way to ensure their application continues to function when the SDK cannot connect to Schematic, the SDKs include built-in fallback behavior. These fallbacks allow you to set what values Schematic uses should the SDK not be able to connect, whether due to network issues, service disruptions, or other connectivity problems.
SDKs provide multiple ways to supply fallback values and configure the call timeouts used to determine when a fallback should be used.
By configuring fallback values at initialization or at the callsite, you can ensure your application gracefully degrades to safe defaults rather than breaking should Schematic be unreachable. This is especially useful for:
- Offline scenarios where users may not have internet connectivity
- Service disruptions where Schematic may be temporarily unavailable
- Network timeouts or connection failures
- Initial page loads where flag values haven’t been fetched yet
This approach provides a lightweight way to handle connectivity issues without requiring additional infrastructure or complex setup.
4. Self-Hosted Cache (DIY Replication)
Some customers combine Schematic’s SDK fallbacks and their own local caching layer using Schematic’s APIs and to build a DIY replication setup.
This approach can work, and we have customers running production systems this way. However, it comes with additional engineering and operational complexity.
How it typically works
A DIY setup usually involves:
- Fetching all relevant company and flag data via Schematic’s APIs nightly
- Storing that data in a local cache (e.g. Redis, Postgres)
- Using that local store as a fallback when live calls fail
This gives you a local source of truth that your application can rely on when Schematic is unreachable.
Our recommendation
If you’re thinking about building this yourself, we strongly recommend using Replicator instead.
Replicator provides the same core architecture—local reads, real-time updates, full cache coverage—but does so in a more robust, battle-tested, and operationally simple way.
DIY replication makes sense when you need highly custom behavior. For most teams, Replicator is the safer and more maintainable solution.
Choosing the Right Strategy
For most teams, Schematic’s default high-availability behavior is sufficient. If you need stronger freshness guarantees, lower latency, or full independence from Schematic’s runtime availability, Replicator is usually the right next step.
If you’re unsure which approach fits your use case, reach out—we’re happy to help you think through the tradeoffs.
