Skip to main content
The Stigg Sidecar is a lightweight service that runs alongside your application and proxies calls to the Stigg API. It provides:
  • Low-latency entitlement evaluations
  • Local caching of entitlements and current usage
  • Subscription to real-time updates for entitlement and usage changes
Node.js applications do not require the Sidecar. The Node.js SDK provides full feature parity with the Sidecar, including low-latency entitlement checks, caching, and real-time updates.

​
Benefits for your application host

Currently, the Sidecar only caches entitlements and current usage. Customer and subscription objects are not cached at this time. Key benefits of using the Sidecar:
  • Reduced CPU and memory usage in the host application compared to embedding the SDK directly
  • Language-neutral API defined with Protocol Buffers and exposed over gRPC
  • Flexible caching: in-memory cache by default, or Redis-based persistent cache
  • Can be scaled together with the main application or as an independent, shared service

​
Fail-safe resilience goals

The main design goal of the Sidecar is to remain operational during network issues while still returning valid read responses. Under normal conditions, reads resolve instantly from the local Redis cache. When the upstream Stigg API becomes unreachable, cached responses are returned directly from Redis. When Redis itself is down, Sidecar attempts a live upstream API call if it is still reachable. If that also fails, it falls back to configurable static default values as a final safety layer. Write paths like ReportUsage and ReportEvents do not return fallback values — errors are returned explicitly and should be handled by your own observability and logging layer using try/catch and structured logging.

​
Synchronous execution and latency guardrails

Sidecar is synchronous by design. The host can call Sidecar and wait safely for an immediate response in the same request path, without risk of background or deferred execution. When a cache miss occurs, Sidecar fetches entitlements from the Edge API, where typical latency is around 100 ms. To block upstream latency from cascading into the host, Sidecar applies a 10-second network timeout (configurable). If the timeout is exceeded, Sidecar returns default values instead of hanging or retrying indefinitely.

​
Isolation from upstream network conditions

Short Stigg API latency spikes do not affect cached reads. Only uncached or Edge-fetched reads are exposed to network conditions. When the Stigg API experiences long or sustained latency or connectivity loss, reads continue being served from cache without degradation. Timeout guardrails prevent external calls from creating cascading delays inside the main application.

​
Security and request handling guarantees

Sidecar must remain internal-only and must not be internet-exposed. Reads always resolve synchronously and immediately from Redis when available. Write-path errors must be handled explicitly at the host level, then surfaced into your own monitoring, alerting, and structured logging layer.