What is SOASAP?

Key takeaways

• Deploy code independently from feature releases
• Evaluate flags locally with O(1) reads
• Synchronize changes in real time via SSE
• Continue operating during outages
• Use the same runtime model across every official SDK

High-level overview

SOASAP is safe release infrastructure powered by feature flags. It gives engineering teams a control plane for turning work on and off in production without tying those decisions to deploy cadence.

SOASAP decouples code deployment from feature activation. You can ship incomplete functionality behind flags, keep mainline integration continuous, and change who sees a feature by updating configuration — not by running another pipeline. That separation reduces the operational risk of feature releases; it does not remove deployment risk entirely — a bad build can still ship — but it limits how far a feature mistake propagates before you can turn it off.

In practice, feature flags are operational controls: kill switches, gradual exposure, environment-specific behavior, and runtime configuration that platform and product teams can reason about under incident load.

The problem SOASAP solves

Teams that ship frequently still hit structural deployment friction:

• Long-lived branches — integration debt accumulates; merges become high-risk events.
• Release trains — fixes and features batch together; one delay blocks everything in the train.
• All-or-nothing deployments — a binary rollout amplifies blast radius when something is wrong.
• Slow rollback — reverting often means another build, another approval, another deploy window.
• Fear of unfinished work in production — teams avoid merging until features are complete, which pushes branching and delays feedback.

These patterns are not tooling failures; they emerge when activation is bound to deployment. Every user-facing change requires a new artifact on the critical path.

SOASAP supports trunk-based development where incomplete code can live on main behind flags. Production binaries stay current; exposure is governed by flag state. Rollouts become configuration changes — flip a boolean, adjust a percentage, or isolate by environment — instead of redeploying the service.

How SOASAP works

SOASAP has a cloud-hosted control plane (dashboard, REST API, flag storage) and SDKs embedded in your applications. The control plane is the source of truth; the SDK is the runtime enforcement layer.

When you change a flag in the dashboard, the update is streamed to connected SDKs over Server-Sent Events (SSE). Each SDK maintains an in-memory local snapshot of the flags for its environment. Application code evaluates flags by reading that snapshot — not by calling SOASAP on the request path.

No network requests are performed during evaluation. Sync is background work; reads are local memory access.

Local-first architecture

Most feature flag systems were designed around request-time evaluation: the SDK or a sidecar asks a remote service (or relay) what the flag value should be. That couples user-facing latency and availability to another network hop.

SOASAP is designed around local evaluation. When your code runs:

if (client.getBool("new-checkout")) {
    // new experience
} else {
    // existing experience
}

the SDK does not perform:

• HTTP requests to SOASAP Cloud
• disk reads on the hot path
• remote API lookups or cache misses that block the thread

Evaluation is a lookup in an in-memory structure — effectively O(1) per flag read.

That design choice has direct production consequences:

• Predictable latency — tail latency on flag reads does not include vendor RTT.
• Resilience — a control-plane outage does not stall request handling if the snapshot is already local.
• Reduced infrastructure dependency — you are not adding a synchronous dependency from every hot path to a third-party API.

Deep dive: Local Evaluation.

Real-time synchronization

Local evaluation only works if the snapshot stays current. After you save in the dashboard or via the REST API, SOASAP streams updates to SDKs over Server-Sent Events (SSE).

Each SDK opens a stream scoped to its environment API key, applies incoming deltas to the snapshot, and swaps updates atomically so readers never observe torn state. On disconnect, the SDK reconnects with backoff while continuing to serve the last known snapshot.

Details: Real-Time Synchronization.

Why SSE?

SOASAP uses Server-Sent Events rather than periodic polling to keep snapshots current.

• Lower network overhead — one long-lived stream replaces repeated poll requests across every instance.
• Faster propagation — changes push when they occur, typically within milliseconds on healthy networks.
• No polling intervals — you are not waiting for the next poll tick before a kill switch takes effect.
• Immediate kill-switch activation — operational reversals behave like live configuration, not like cache TTL luck.

Polling can work for low-frequency updates; SOASAP optimizes for teams that treat flags as production controls under incident load.

Persistent cache and cold starts

Memory alone is not enough across process restarts. SOASAP SDKs persist the latest snapshot to local storage so cold starts do not block on the first network round-trip.

Storage varies by runtime, but the model is the same:

• iOS — UserDefaults or equivalent app sandbox storage (Swift SDK planned)
• React Native — AsyncStorage
• Android / Kotlin — DataStore or app-private files
• .NET, Node.js, Python — local disk cache under a configurable path

Startup reliability improves because health checks and first requests can use cache-backed values immediately. SSE catches up in the background. This pairs with preload options so hosts do not await sync before accepting traffic.

Details: Persistent Cache and Non-Blocking Startup.

Offline-first operation

Production networks fail. SOASAP SDKs continue to evaluate flags when:

• SOASAP Cloud or the management API is unavailable
• Internet connectivity is lost between your service and SOASAP
• The SSE connection drops temporarily

The SDK serves the last known snapshot. Code-level defaults still apply for keys that were never synced. The philosophy is explicit: prefer stale configuration over unavailable configuration. A known-off kill switch frozen during an outage is operable; a flag read that throws or times out is not.

This is a deliberate trade for runtime systems: you accept bounded staleness during partitions in exchange for continued request handling. Operational runbooks should document which flags are safe to freeze and which require freshness.

Details: Offline Operation.

What happens when things go wrong?

Production systems fail in predictable ways. SOASAP is designed so flag reads stay usable:

Dashboard changes may lag during extended outages, but request paths should not block on SOASAP availability. Document which flags are safe to serve stale in runbooks.

Troubleshooting: Flag Not Updating, SSE Disconnected.

Production design principles

SOASAP SDKs follow a consistent set of runtime rules:

• Never block application startup — restore cache and sync in the background; use preload so the process can serve traffic while SSE connects.
• Never perform network calls during evaluation — the hot path reads memory only; sync is off-thread or async infrastructure.
• Prefer stale data over failure — serve the last snapshot when the control plane is unreachable; avoid failing open requests because a vendor API timed out.
• Keep evaluation O(1) — flag reads stay constant-time lookups suitable for per-request and tight-loop use.
• Continue operating during outages — decouple end-user availability from SOASAP Cloud uptime for reads already covered by the snapshot.
• Make infrastructure failures invisible to end users — incidents surface as delayed dashboard updates, not as user-visible errors on flag checks.

Related: Production Safety.

What SOASAP is not

Clear positioning helps teams choose the right tool:

SOASAP is not:

• An experimentation platform with built-in statistical analysis of variants
• An analytics or product analytics suite
• An A/B testing product with hypothesis management and significance testing
• A customer data platform for identity resolution or audience building
• A self-hosted flag server you operate and patch yourself

SOASAP focuses on feature delivery, release safety, runtime configuration, and operational control in live systems. If your primary need is rigorous experiment design, SOASAP may complement other tools — but it is architected for engineers shipping and operating services under real failure modes.

Quick code example

The read path is the same across SDKs; naming differs slightly by language:

if (client.getBool("new-checkout")) {
    // new experience
} else {
    // existing experience
}

Register the client once at startup with your environment API key, enable preload where available, and treat missing keys with explicit defaults in code.

Supported SDK ecosystem

All official SDKs share the same runtime contract:

• Local evaluation — O(1) reads from an in-memory snapshot
• SSE synchronization — real-time updates from SOASAP Cloud
• Persistent cache — snapshot survives process restarts
• Offline operation — last-known snapshot when the network or API is down
• Non-blocking startup — preload and background sync; do not block the host on first fetch

Platform guides:

• .NET
• Node.js
• Python
• React
• Angular
• React Native
• Kotlin
• Swift (coming soon)

SDK Installation — packages and install commands.

Next steps

SOASAP is not only a dashboard for toggles. It is release infrastructure where production behavior — latency, startup, and failure modes — is defined by local-first evaluation and resilient sync.

• Quick Start — evaluate a flag in minutes
• SDK Installation — packages and platform guides
• Architecture — local evaluation, SSE, cache, offline operation
• Feature Flags — types, defaults, and usage patterns
• API Reference — automate projects, environments, and flags

Also see Why SOASAP and Core Concepts for organizations, environments, and API keys.