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
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.
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.
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.
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.
