What is SOASAP?

Key takeaways

• Deploy independently — code releases decoupled from feature activation
• O(1) local reads — zero network calls on the evaluation path
• Real-time SSE sync — configuration changes push to connected SDKs
• Outage resilience — last-known snapshot keeps request paths alive
• Unified SDK model — same runtime contract 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.

Key characteristics

• O(1) local evaluation — Flag reads are constant-time lookups in an in-memory snapshot; no network calls on the hot path.
• Real-time synchronization via SSE — Configuration changes push to connected SDKs over Server-Sent Events.
• Persistent local cache — Snapshots survive process restarts via disk-backed storage.
• Offline-first operation — The last known snapshot continues to serve when the control plane or network is unavailable.
• Non-blocking startup — Cache restore and SSE connect in the background; the host does not wait for sync before serving traffic.
• Shared architecture across all SDKs — Every official SDK follows the same runtime contract for evaluation, sync, and cache.

Official SDKs

All official SDKs implement the same local-first runtime model:

• .NET
• Node.js
• Python
• React
• Angular
• React Native
• Kotlin

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 and flag storage) and SDKs embedded in your applications.

The cloud control plane distributes configuration. SDKs maintain local snapshots. Applications evaluate flags locally from memory.

When you change a flag in the dashboard, the update streams to connected SDKs over Server-Sent Events (SSE). Each SDK holds an in-memory local snapshot scoped to its environment API key. Application code reads that snapshot — not SOASAP Cloud — on the request path.

No network requests run 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 a change in the dashboard, SOASAP streams updates to SDKs over Server-Sent Events (SSE).

Each SDK:

• Opens a stream scoped to its environment API key
• Applies incoming deltas and swaps updates atomically — readers never observe torn state
• Reconnects with backoff on disconnect while serving 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

Health checks and first requests use cache-backed values immediately. SSE catches up in the background.

Preload options let hosts accept traffic without awaiting the first sync.

Details: Persistent Cache and Non-Blocking Startup.

Offline-first operation

SOASAP SDKs continue to evaluate flags when the control plane, network, or SSE stream is unavailable:

• SOASAP Cloud is unavailable
• Connectivity between your service and SOASAP is lost
• The SSE connection drops temporarily

The SDK serves the last known snapshot. Code-level defaults apply for keys never synced.

The model is prefer stale configuration over unavailable configuration — bounded staleness during partitions in exchange for continued request handling.

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.

Troubleshooting: Flag Not Updating, SSE Disconnected.

Common use cases

• Kill switches — Disable a feature instantly without redeploying. Flip a boolean in the dashboard; connected SDKs receive the change over SSE within milliseconds.
• Gradual rollouts — Expose a feature to a percentage of traffic or specific segments before full release. Adjust exposure in configuration, not in code.
• Trunk-based development — Merge incomplete work to main behind flags. Production binaries stay current; activation is governed by flag state, not branch strategy.
• Runtime configuration — Change behavior in production without a new build or deploy window. Numeric and string flags support thresholds, limits, and feature parameters.
• Environment-specific behavior — Isolate flag state per environment via API keys. Development, staging, and production each maintain independent snapshots.
• Emergency rollback — Revert a feature to its previous state by updating flag configuration. No pipeline, no artifact rebuild, no deploy approval required.

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.

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 are listed under Official SDKs above. Swift is planned. See SDK Installation for 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 Keys — environment-scoped keys for SDK sync

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