Server Core Overview

Statsig Server Core

Statsig Server Core is the second generation of Server SDKs: a full rewrite with a shared, performance-focused core library that delivers improved performance and feature maturity across all Server SDKs. Server Core SDKs include:

• Faster evaluation: A shared Rust evaluation engine that evaluates 3-5x faster than native code SDKs.
• Better non-evaluation performance: More efficient network and CPU usage, plus ongoing performance optimizations.
• Features new to Server SDKs: Parameter Stores, Contextual Multi-Armed Bandits, and more.
• Additional capabilities: Observability Interface, streaming config changes (from the Statsig Forward Proxy), and more.

Availability across SDKs

Technical differences

Build process: Statsig Server Core uses a core library written in Rust, with bindings for other languages. In most cases, the development experience is unchanged and performance is superior. Because the Rust code must compile into a binary compatible with your development and deployment environments, consider the following:

• Choosing the right build: In most cases, the SDK's package manager automatically installs the correct version. The exception is Java, where the SDK prints the correct build if it isn't included at runtime.
• Managing lockfiles: If your deployment and development environments require different builds (which is common), include both versions in a lockfile such as package-lock.json.
• Untested environments: Certain environments, such as the edge, aren't compatible with this build process. Use native SDKs in those cases.

New Configuration Spec: Server Core uses a smaller "ruleset", or configuration spec. If you use the spec directly, your logic and parsing will have to change.

Event Logging

Server Core SDKs, starting in v0.4.0, use a new event logging architecture. During normal operation, events stream to Statsig servers. During outages on the event logging endpoint, the SDK throttles or drops events to allow the service to start healthy before processing steady-state traffic. The following parameters tune this behavior:

- event_logging_max_queue_size: Controls batch size (default 2000).  Note that exceeding the backend request size limit (10MB) will drop requests
- event_logging_max_pending_batch_queue_size: Controls max pending batches (default: 20).  The tradeoff here is increased memory usage to buffer events when requests fail if you increase it, and losing additional events if you decrease it
- disable_all_logging: Completely disables event logging

+----------------+     +----------------+     +----------------+
| Event Sources  |     | Event Queue    |     | Flush Triggers |
|----------------|     |----------------|     |----------------|
| - Gate Checks  |---->| - Pending      |     | - Scheduled    |
| - Config Reads |     |   Events       |     |   (Time-based) |
| - Custom Events|     | - Batches      |<----| - Manual       |
+----------------+     +----------------+     | - Shutdown     |
                             |                +----------------+
                             v
                      +----------------+
                      | Flush Process  |
                      |----------------|
                      | - Batch Events |
                      | - Send to API  |
                      | - Process      |
                      |   Response     |
                      +----------------+
                           /   \
                          /     \
                         v       v
+---------------------------+---------------------------+
|      On Request Failure   |     On Request Success    |
|---------------------------|---------------------------|
| - Double interval         | - Halve interval          |
|   (max: 60000ms)          |   (min: 1000ms)           |
| - Retry errors            | - No specific limit       |
|   up to 5 times           |   flush mechanism         |
+---------------------------+---------------------------+

Support