> ## Documentation Index
> Fetch the complete documentation index at: https://docs.stigg.io/llms.txt
> Use this file to discover all available pages before exploring further.

# How entitlement checks work

Every time your application decides whether a customer can use a feature, it runs an entitlement check. Because these checks sit on the critical path of your product, Stigg is built so that they stay fast and keep working even when the Stigg API can't be reached.

This section covers what entitlements are, how to check them in your application, and how to deploy Stigg for the availability and scale you need.

## The request path

```mermaid theme={null}
flowchart LR
  A[Your application] --> B[Stigg SDK or Sidecar]
  B --> C{Cached?}
  C -- Yes --> D[Return from cache]
  C -- No --> E[Stigg API]
  E --> D
```

1. Your application asks the SDK (or the [Sidecar](/documentation/high-availability-and-scale/sidecar/overview)) whether a customer has access to a feature.
2. If the customer's entitlements are cached, the answer comes straight from the cache, without a network call. The Node.js SDK and the Sidecar keep an in-memory cache, which stays current through polling or real-time updates. Other backend SDKs call the Stigg API on every check.
3. Otherwise, the SDK fetches the entitlements from the Stigg API, which runs at the edge location closest to your servers.

See [Caching](/documentation/managing-customers-and-subscriptions/entitlements/caching) for how the in-memory and persistent caches work.

## When the Stigg API is unreachable

Stigg keeps your application running through network issues and outages:

* **Cached entitlements** keep answering checks while the SDK retries in the background.
* **Fallback values** decide access when there's no cached data. You can set them globally or per feature. See [Fallback strategy](/documentation/managing-customers-and-subscriptions/entitlements/fallback-strategy).
* **Buffered usage** is held by the SDK and reported once connectivity returns. See [Errors, retries, and usage buffering](/documentation/high-availability-and-scale/errors-retries-and-usage-buffering).

## Choosing a setup

| Setup | What it is | When to use it |
| - | - | - |
| Node.js SDK with in-memory cache | Entitlements cached in each process of your application | Most Node.js applications |
| [Persistent cache](/documentation/high-availability-and-scale/persistent-caching) | Entitlements stored in your Redis cluster and shared across processes | Large fleets, serverless environments, or processes that restart often |
| [Sidecar](/documentation/high-availability-and-scale/sidecar/overview) | A service that runs next to your application and proxies calls to the Stigg API | Backend languages other than Node.js, when you want local caching and real-time updates |
| [BYOC](/documentation/high-availability-and-scale/byoc/overview) | Stigg services deployed in your own cloud account | Strict data residency, security, or network isolation requirements |


## Related topics

- [What is an entitlement](/documentation/managing-customers-and-subscriptions/entitlements/overview.md)
- [Best practices](/documentation/managing-customers-and-subscriptions/entitlements/best-practices.md)
- [High availability architecture](/documentation/high-availability-and-scale/high-availability-architecture.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.