Sidecar

The Stigg Sidecar is a tiny service that runs alongside your main application, acting as a proxy between the host and the Stigg API. The service provides low latency entitlement checks, handles caching, and subscribes to real-time entitlement and usage data updates.

The benefits of deploying the Sidecar service:

• Less CPU consumption and memory footprint for the host application when compared to embedding the SDK directly.
• Language neutral API defined in Protocol Buffers accessible over gRPC.
• Support for in-memory cache or external cache (like Redis) for entitlements and usage data.
• Scaled together with the main application, or independently if deployed as a standalone service.

​

Overview

The sidecar service can be deployed together with the host application/service by utilizing the sidecar pattern - meaning each application has a sidecar container next to it which it can send requests to.
Alternatively it can be deployed as a standalone service which can be accessed remotely over an exposed port.

The service can be scaled horizontally to support a higher volume of requests, but keep in mind that if in-memory cache is used, there will be a higher ratio of cache misses. In case of a cache miss, the service will fetch the data over the network directly from API, and update the cache to serve future requests.

The sidecar is not intended to be exposed to the internet or to be accessed from a browser.

Sidecar service can be deployed in the same network namespace (or same K8 Pod), as the main application.
Once entitlement data is fetched from the Stigg API, it is persisted in the local or external cache.

Local cache invalidation is handled by the Sidecar service. If using an external cache, an instance of the Persistent Cache Service must be deployed as well to handle cache updates, as illustrated below:

​

Running the service

​

Prerequisites

• Docker
• Redis instance, if a persistent cache is in use

​

Usage

Login to AWS ECR:

aws ecr-public get-login-password --region us-east-1 | docker login --username AWS --password-stdin public.ecr.aws/stigg

Run the service:

docker run -it -p 8443:8443 \ 
  -e SERVER_API_KEY="<SERVER_API_KEY>" \
  public.ecr.aws/stigg/sidecar:latest

​

Available options

Execution of the Sidecar service can be customized using the following environment variables:

​

Error handling

When the Sidecar encounters startup errors, such as an invalid API key or network errors to the Stigg API, it continues to run and serves entitlements from the:

1. Persistent cache (if available)
2. Global fallback strategy

​

Service monitoring

​

Health

The service exposes two endpoints accessible via HTTP:

GET /livez

Returns 200 if the service is alive.

Healthy response:

{ "status": "UP" }

GET /readyz

Returns 200 if the service is ready.

Healthy response:

{ "status": "UP" }

​

Metrics

The Sidecar exposes a GET /metrics endpoint that returns service metrics in Prometheus format.

This endpoint includes both system-level and Sidecar-specific metrics. These metrics are helpful for monitoring the health and performance of your Sidecar service.

​

Persistent caching

In order for the cached data to survive service restarted, or shared across multiple instances of the Sidecar service, you can use Redis as the cache layer by providing the REDIS_* environment variables:

docker run -it -p 8443:8443 \
    -e SERVER_API_KEY="<SERVER_API_KEY>" \
    -e REDIS_ENVIRONMENT_PREFIX="production" \
    -e REDIS_HOST="localhost" \
    public.ecr.aws/stigg/sidecar:latest

​

Global fallback strategy

Global fallback strategy can be set by providing the Sidecar service with the ENTITLEMENTS_FALLBACK environment variable. It expects a value in a JSON object in a string format.

For example, the following global fallback configuration JSON structure:

{
  'feature-01-templates': {
    hasAccess: true,
    usageLimit: 1000,
  },
  'feature-02-campaigns': {
    hasAccess: true,
    isUnlimited: true
  }
}

Can be formatted using JSON.stringify and then set as value of ENTITLEMENTS_FALLBACK when running the container:

docker run -it -p 8443:8443 \ 
  -e SERVER_API_KEY="<SERVER_API_KEY>" \
  -e ENTITLEMENTS_FALLBACK='{"feature-01-templates":{"hasAccess":true,"usageLimit":1000},"feature-02-campaigns":{"hasAccess":true,"isUnlimited":true}}' \
  public.ecr.aws/stigg/sidecar:latest

​

Offline mode

During local development or testing, you might want to avoid making network requests to the Stigg API.
To do this, you can run the Sidecar service in offline mode by enabling the offline option. When enabled, API key validation will always succeed, regardless of the key provided.

docker run -it -p 8443:8443 \
    -e SERVER_API_KEY="localhost" \
    -e OFFLINE=TRUE \
    public.ecr.aws/stigg/sidecar:latest

In offline mode, the Sidecar respects the global fallback strategy, and entitlement evaluations are limited to the values defined as fallback entitlements. All other Sidecar service methods will effectively become no-ops. For example:

docker run -it -p 8443:8443 \ 
  -e SERVER_API_KEY="<SERVER_API_KEY>" \
  -e OFFLINE=TRUE \
  -e ENTITLEMENTS_FALLBACK='{"feature-01-templates":{"hasAccess":true,"usageLimit":1000},"feature-02-campaigns":{"hasAccess":true,"isUnlimited":true}}' \
  public.ecr.aws/stigg/sidecar:latest

​

Interaction with the Sidecar service

Interacting with a running Sidecar service is possible using the Sidecar SDK: