Why SOASAP

Why teams choose SOASAP

Most feature flag platforms evaluate flags at request time — each read may call a remote service or relay. SOASAP is built around local evaluation: SDKs hold a synchronized snapshot in memory and resolve flag values without network calls on the hot path.

• O(1) local evaluation — constant-time reads from an in-memory snapshot
• No network requests during evaluation — sync runs in the background, not on the request path
• Real-time synchronization via SSE — configuration changes push when they occur
• Persistent cache across restarts — snapshots restore from disk on cold start
• Offline operation during outages — the last known snapshot continues to serve
• Consistent behavior across SDKs — the same runtime contract on every platform

The result is lower latency, reduced infrastructure dependency, and more predictable production behavior.

Introduction

Most feature flag platforms optimize for dashboards, targeting rules, and management workflows. Those capabilities matter for operators, but they are not what your application executes on every request.

SOASAP focuses on runtime behavior. The critical question is not where a flag is created — it is how evaluation behaves inside production applications when traffic spikes, networks partition, or you need to disable a feature immediately.

That focus shapes five architectural pillars:

• Local evaluation — flag reads are in-memory lookups, not remote API calls
• Real-time synchronization — configuration changes propagate over SSE, not poll intervals
• Persistent cache — snapshots survive process restarts and cold starts
• Offline-first operation — evaluation continues from the last known snapshot when the control plane is unreachable
• Unified SDK architecture — every official SDK implements the same runtime contract

This page explains why those choices exist and what operational outcomes they produce. It assumes you already understand feature flags; it does not re-teach the concept.

Traditional feature flag platforms vs SOASAP

Why this matters

Feature flags are frequently evaluated on hot paths — per-request routing, kill switches, feature gates in tight loops, and runtime configuration checks under load.

How a platform evaluates flags directly affects:

• Latency — remote evaluation adds RTT and relay hops to every read
• Startup behavior — cold starts may block on the first network fetch without persistent cache
• Resilience — control-plane outages can stall request handling when evaluation is remote
• Operational safety — kill switch propagation speed depends on sync model, not poll intervals

SOASAP treats flags as local configuration with background synchronization — not as another service dependency on the request path.

Local evaluation vs remote evaluation

Traditional feature flag systems often evaluate at request time. The application asks a remote service — or a relay in front of it — for the current flag value before continuing work.

SOASAP inverts that dependency. The SDK maintains a local snapshot synchronized in the background. Evaluation reads that snapshot directly.

SOASAP performs no network requests during evaluation. Every read is an in-memory lookup — effectively O(1) per flag key. Sync is background infrastructure; the hot path does not wait on SOASAP Cloud.

That distinction has direct production consequences:

Under high traffic, remote evaluation turns every flag check into a potential synchronous dependency. A service handling millions of requests per minute does not add another network hop per flag read without affecting tail latency and failure domains. Local evaluation keeps flag checks off the critical path.

Deep dive: Local Evaluation.

Why real-time SSE

Local evaluation requires a current snapshot. The question is how updates reach running applications.

Polling asks the server repeatedly whether anything changed. Even with efficient delta endpoints, polling introduces:

• Delayed updates — changes apply only after the next poll interval
• Repeated requests — every instance polls on a schedule regardless of whether flags changed
• Unnecessary traffic — steady-state overhead grows with fleet size and poll frequency

Server-Sent Events (SSE) push updates when they occur:

• Push-based updates — the control plane notifies subscribers on change
• Immediate propagation — healthy connections receive deltas within milliseconds
• Lower steady-state overhead — one long-lived stream per SDK replaces periodic full or delta polls

Kill switches and operational rollbacks depend on propagation speed. A 30-second poll interval means a disabled feature may remain active across your fleet for up to 30 seconds. SSE treats flag changes as live configuration events, not cache refresh luck.

Each SDK opens an SSE stream scoped to its environment API key, applies incoming deltas atomically, and reconnects with backoff on disconnect while continuing to serve the last known snapshot.

Deep dive: Real-Time Synchronization.

Why persistent cache

In-memory snapshots alone do not survive process restarts. Without disk-backed state, every cold start must wait for the network before flags are trustworthy.

SOASAP SDKs persist the latest snapshot to local storage. Startup restores cache first; synchronization catches up in the background.

This matters in environments where processes restart frequently:

• Cold starts — serverless and scale-to-zero runtimes can evaluate flags before the first SSE frame arrives
• Container restarts — orchestrator health checks and first requests do not block on SOASAP availability
• Rolling deployments — new pods serve traffic with the previous snapshot while SSE connects
• Autoscaling events — new instances join the fleet without a synchronous bootstrap call to the control plane

Storage mechanism varies by platform — disk files, DataStore, AsyncStorage, app sandbox storage — but the runtime model is identical: restore, serve, sync.

Deep dive: Persistent Cache and Non-Blocking Startup.

Why offline-first

Production networks and third-party services fail. A feature flag system that blocks evaluation when the control plane is unreachable adds a synchronous dependency to every hot path that checks a flag.

SOASAP SDKs continue evaluating from the last known snapshot when:

The design principle is explicit: prefer stale data over unavailable data. A kill switch frozen at false during an outage is operable — users see the safe path. A flag read that throws or times out on every request is not.

That is a deliberate trade-off. You accept bounded staleness during partitions in exchange for continued request handling. Not every flag tolerates staleness equally — operational runbooks should document which flags are safe to freeze and which require freshness guarantees.

Deep dive: Offline Operation.

Unified SDK architecture

Most platforms evolve SDKs independently. Capabilities diverge: one runtime gets streaming sync, another polls; one persists to disk, another does not; startup semantics differ across languages.

SOASAP SDKs intentionally share the same runtime model. Every official SDK implements:

• Local evaluation — O(1) reads from an in-memory snapshot
• SSE synchronization — push-based 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 — restore cache and sync in the background; preload so hosts do not await first fetch

Consistency matters for multi-platform teams. A mobile client, a Node.js API, and a .NET worker can reason about the same failure modes, startup sequence, and rollback behavior without per-platform caveats.

Platform guides: SDK Installation.

Production outcomes

The architectural decisions described above are not implementation details.

They directly influence latency, startup behavior, outage resilience, deployment safety, and operational control in production systems.

Architecture choices translate into measurable operational behavior. Each outcome below maps directly to a design decision on this page — not to dashboard features.

These outcomes compound. A team running high-throughput services, frequent deploys, and multi-platform clients benefits when flag infrastructure behaves like local configuration with background sync — not like another service on the request path.

Related: Production Safety.

SOASAP at a glance

• ✓ O(1) local evaluation
• ✓ Real-time SSE synchronization
• ✓ Persistent cache
• ✓ Offline-first operation
• ✓ Non-blocking startup
• ✓ Unified SDK architecture

These properties define how SOASAP behaves in production — before you dive into platform-specific SDK guides or architecture deep dives.

Summary

SOASAP is not differentiated by dashboard features or targeting rule editors. It is differentiated by runtime architecture — how flags are evaluated, synchronized, cached, and served when production systems fail.

The core model is straightforward:

• Evaluate locally — O(1) in-memory reads on the hot path
• Synchronize in real time — SSE pushes changes when they occur
• Persist state — snapshots survive restarts and cold starts
• Remain operational during outages — serve the last known snapshot rather than failing requests

Continue with:

• Architecture — Local Evaluation — evaluation model and read path
• Real-Time Synchronization — SSE lifecycle and reconnect behavior
• Persistent Cache — cold starts and storage
• Offline Operation — failure modes and staleness trade-offs
• Quick Start — evaluate a flag in minutes

Background: What is SOASAP and Core Concepts.