Skip to main content
Stigg is a hot-path runtime: entitlement, credit, and limit checks run inline in your request path, so they must stay fast and keep working even when a network error occurs or Stigg’s services are unavailable. Two paths are treated as mission-critical:
  • Access decisions: the backend SDKs and the Sidecar evaluate entitlement checks against a local cache, so a decision doesn’t wait on a network round trip to Stigg. If Stigg can’t be reached, checks continue to be served from the cache. See the Sidecar benchmarks for measured latency.
  • Usage reporting: usage is buffered by the SDK and retried until it reaches Stigg, so a temporary outage doesn’t block your request or lose the measurement. Learn more in Errors, retries, and usage buffering.
Stigg runs on AWS and is split into two planes:
  • Management API: the GraphQL and REST APIs, along with the background workers that process webhooks, integrations, and scheduled jobs. It runs as containerized services on Amazon EKS (Kubernetes) and is deployed through a GitOps pipeline.
  • Edge API: serves entitlement, usage, and catalog reads from a CDN, as close as possible to the caller. It runs independently of the Management API, so reads keep working even if the Management API is degraded. Learn more in Accessible from anywhere.
The Management API is backed by a 99.99% uptime SLA.

Related topics

Local caching and fallback strategyAccessible from anywhereStatus page