LAB429/ Cheetah product page ↗

Cheetah / Cheetah documentation

Presets and component sets

A preset creates implementations that are intended to work as one family. It does not create network listeners or decide which server roles run in a process. The returned ComponentSet is composition material for those later decisions.

Choose the implementation family

ConstructorIntended topologyCoordination and storageImportant limits
create_dev_components()one processin-memory registry, direct dispatch, in-memory correlation, history, notification, and deduplicationstate disappears with the process; default authentication and tracing are development-only
create_redis_components()several processes or replicasRedis-backed presence, dispatch, correlation, notification, history, deduplication, quota, contexts, and browser-window topologyrequires explicit authentication and deployment identity; parser registry is not created
create_production_components()guarded Redis baselinethe Redis family plus construction-time security checksstill does not supply the surrounding production platform
create_shared_tenant_nodes()mutually untrusted tenants on shared infrastructurevalidates an accepted tenant-aware family and constructs all three roles togetheronly the audited surface and components are accepted; this is a separate composition path

Changing preset changes how state and coordination are implemented. It does not require a different command API in product code.

Development preset

from servercheetah.presets import create_dev_components

components = create_dev_components(
    node_id="development-1",
    api_keys={"development-key": "development-user"},
    history_max_per_stream=1000,
    enable_worker_topology=True,
)

The development family includes an in-memory connection registry, direct dispatcher, RPC correlator, history store, response notifier, deduplicator, parser registry, no-op resource quota, and no-op tracer. enable_worker_topology=True also creates in-memory context and browser-window registries.

Use this family when one process owns the complete test or development system and losing its state is acceptable. SimpleAuthProvider, fixed local credentials, a no-op tracer, and process-local state are not production defaults. Two calls to create_dev_components() produce two unrelated object graphs; roles that must cooperate need members of the same set.

Redis preset

components = create_redis_components(
    redis_client=redis_client,
    node_id="app-1",
    auth_provider=auth_provider,
    deployment_id="dep_01234567-89ab-4def-8123-456789abcdef",
    tracer=tracer,
    parser_registry=parser_registry,
)

Every cooperating process uses the same stable deployment_id and compatible Redis and payload-storage services. Built-in Redis keys and publication channels are scoped by that deployment namespace. Each concurrently running process needs a unique node_id; an orderly replacement can reuse an ID, but overlapping processes must not. Cheetah does not centrally reserve node IDs, so deployment tooling owns that guarantee.

The Redis preset creates a bounded delivery-backlog quota as part of the dispatcher family. It also creates deployment-scoped context and browser-window registries unless explicit replacements are supplied. The context registry completes its capability check during ComponentSet.start(), because synchronous preset construction cannot safely probe an async Redis server. If the required atomic capability is unavailable, the registry selects its conservative process-local behavior for that lifetime.

The preset does not create a parser registry. Supply one before relying on registered parser definitions. Tracing defaults to a no-op unless supplied. History retention, stream and index TTLs, and optional large-payload spillover are configuration choices; a file-backed spill store must be shared by every node that may need to read those payloads.

The Redis client's response-read timeout must exceed the dispatcher's blocking-read timeout. With the default five-second dispatcher block, the preset documentation recommends a 30-second Redis socket timeout.

Production preset

The production constructor builds the Redis-backed family and adds selected fail-fast checks:

  • it requires a deployment ID;
  • it rejects SimpleAuthProvider;
  • it rejects an explicitly supplied NoOpAdminAuth;
  • it refuses a non-strict WebSocket transport requirement;
  • it warns when administrative authentication is absent or tracing is disabled;
  • its dispatcher refuses readiness while legacy pending command streams would be stranded.

The returned set retains the strict-transport requirement. Passing it through the component-set-aware create_websocket_node(components=..., config=...) form rejects a conflicting WebSocketNodeConfig. Low-level calls that pass individual components remain available, but they do not carry that preset-level proof.

This is a guarded component baseline, not a complete production environment. It does not create TLS termination, a trusted reverse proxy, credential issuance, rate policy, audit workflow, diagnostics authentication at every mount, observability storage, backups, deployment manifests, or incident response. Those controls belong to the host and platform.

Shared multi-tenant composition

Ordinary mode does not require a tenant. When mutually untrusted tenants share one service, use create_shared_tenant_nodes() rather than constructing ordinary nodes and later adding a tenant field.

The shared constructor validates the component family, requires tenant-aware REST and App configuration, requires strict WebSocket transport and administrative authentication, and returns a restricted SharedTenantAppNode. Product code enters that surface through an AuthenticatedTenantPrincipal; a composed identity string is not authentication proof.

Only implementations explicitly accepted by the shared-tenancy audit are allowed. A custom class does not become safe merely by implementing the same method signatures. Parser registries and central policy sources also need the shared boundary's accepted behavior.

What ComponentSet carries

The required members are auth, registry, dispatcher, correlator, history, response_notifier, deduplicator, tracer, and node_id. The current set can additionally carry resource quota, deployment identity, administrative authentication, parser registry, context and browser-window registries, preset type, and a required WebSocket transport mode.

The set is mutable composition material, not a runtime certificate. A maintained preset constructs a known family, but manually constructing or changing the dataclass bypasses those compatibility assumptions. When replacing one responsibility, verify its behavioral contract with every consumer, not only its type annotation.

Continue to Node roles and factories to turn the selected family into services.