Deploy and scale
Scale the role receiving pressure rather than duplicating the whole diagram. Long-lived connections, returned data, and product work have different resource profiles and different failure boundaries.
One process is a valid deployment
The application, WebSocket, and REST roles can share one host and one in-memory component family. This minimizes moving parts and is often the right first deployment. It does not provide cross-process coordination or persistence across process restart.
Run only one such host for a given in-memory routing domain. A second host has a separate registry and cannot deliver to sockets owned by the first.
Redis creates a shared coordination domain
Use compatible Redis-backed components when roles run in separate processes or when a role has several replicas. Every participant uses the same stable deployment ID and backing services. Give each process a unique node ID.
The shared family coordinates current routes, durable logical-client command mailboxes, correlation metadata, notifications, history, deduplication, contexts, and browser-window topology. If history payloads spill to external storage, every role that must read them needs compatible access to that store.
Redis is not a durable product task system. An admitted command remains in its logical-client mailbox within the configured delivery and retention policy; node wake-ups are disposable hints recovered by reconnect checks and periodic sweeps. Response notifications are also signals, so readers consult retained history after a missed notification. Durable application jobs still need their own identity and checkpointing.
Scale WebSocket ownership
Each upgraded connection belongs to the WebSocket process that accepted it. A capable load balancer can distribute new upgrades across hosts; the established socket remains on its owner. On reconnect, a client may land elsewhere, and the new registration replaces the old route using stable client identity and runtime-instance fencing.
Cheetah does not require sticky sessions for reconnect. The edge must support upgrades, appropriate idle timeouts, graceful drain, and truthful external scheme handling.
During drain, stop admitting new connections, allow or fence in-flight sends according to the deployment policy, and let clients reconnect through the healthy pool before terminating the old process.
Scale returned-data ingestion
Any compatible REST host can authenticate and settle returned messages against shared deduplication, history, registry, and correlation state. Ordinary round-robin HTTP routing is appropriate. More REST replicas do not help when their common Redis or payload store is unavailable.
Align proxy limits with the REST role so an oversized message receives a predictable response at one documented boundary.
Scale application work
Application hosts create commands and run product APIs or jobs. A pending future remains in the process that registered it. Correlation tells a REST host where to publish a terminal notification; it does not migrate the caller if that process dies.
The terminal message can still be retained and found by another process. Long-running product work that must resume should store a durable job record and reconcile it with Cheetah history after restart.
Separate observation when useful
Redis-backed inspectors can run in a dedicated observation host without accepting client connections or issuing commands. Mounting only read diagnostics keeps the role narrow. Enabling the DevConsole control API turns it into a command-producing application role and changes its authorization and incident consequences.
Supply the platform around the roles
Cheetah does not publish a universal reverse proxy, DNS, certificate, container, Kubernetes, or cloud deployment bundle. The repository supplies role architecture and focused multi-node tests. The product supplies the concrete platform, capacity model, regional strategy, backups, monitoring, and rollout process.