One system across several server hosts
The application-facing, WebSocket, and returned-data roles can share one process for as long as that deployment is sufficient. When their pressures diverge, Cheetah can run them as separate processes or hosts over one compatible coordination domain without changing what a command or returned outcome means.
Distribution changes ownership and failure domains. It does not turn sockets, waiters, or application work into stateless objects.
Split a responsibility for a reason
Long-lived client connections, bursts of returned HTTP data, and product-facing application requests have different resource profiles. A deployment may therefore run several WebSocket roles for connections, several REST roles for ingestion, and a separately scaled set of application roles.
Each process creates a compatible Redis-backed component family using the same deployment namespace and distinct node identity. The shared domain carries connection records, logical client mailboxes, pending correlation metadata, notifications, history, deduplication, contexts, and selected topology state. The network listener, live socket, and waiting future remain owned by the process that created them.
This distinction explains the complete path:
- An application role registers response correlation and admits a command for a logical client.
- The Redis dispatcher places it in that client's ordered mailbox and signals the current WebSocket owner.
- The owning WebSocket role claims the mailbox head, binds the attempt to the current runtime instance, and performs at most one automatic socket send.
- The client posts progress or a terminal outcome to a REST role.
- The REST role authenticates, validates, fences, deduplicates, and retains the message.
- Shared correlation notification wakes the application process that owns the local waiter; product code can then read the retained evidence.
Disposable notifications accelerate work but are not the durable record. Periodic mailbox reconciliation recovers admitted commands from a missed wake hint, and retained history remains available after a missed response notification.
Understand what survives a process loss
If an application process stops, its local waiter disappears even if a late client result later reaches shared history. If a WebSocket process stops, another process can observe the old shared connection record but cannot inherit the vanished socket. The client must reconnect before another role owns a live route.
Work that is still provably unattempted can follow the logical client to a replacement runtime. Once a send attempt begins, Cheetah does not automatically replay an uncertain send. The application must interpret delivery evidence and reconcile any external side effect that may have occurred.
Redis therefore coordinates the implemented server roles; it does not provide transparent exactly-once execution, a durable product job queue, or automatic business recovery.
What the repository verifies
The maintained multi-node integration suites create separate WebSocket, REST, and application component bundles over shared fake Redis. They verify shared presence, local and cross-node dispatch, retained history, deduplication, cross-node RPC resolution, user isolation, reconnection, concurrent connections and commands, cleanup, timeouts, and history ordering.
Product01 also contains split-role development launchers, and the DevConsole Harness has a managed Redis adapter for bounded scenarios and structured reports. These are useful integration and operational evidence. They are not packaged production deployment assets.
For a focused repository check:
serverCheetah\venv\Scripts\python.exe -m pytest \
serverCheetah\tests\integration\test_multinode_fakeredis.py \
serverCheetah\tests\integration\test_multinode_scenarios.py -qThe tests exercise the coordination contracts without requiring a production Redis design. Use real Redis and deployment-specific failure tests before accepting a real operating environment.
The surrounding platform still matters
Cheetah does not ship a cloud control plane. The deployment owns TLS termination, routing, load balancing, Redis availability and persistence, compatible payload storage, secret distribution, health and readiness policy, draining, upgrades, observability, backups, and incident response.
Scale each role only when measurements justify it, keep component families compatible, and verify the complete path during rollout. The system remains understandable because product actions, client identities, authority decisions, and returned evidence retain the same meaning in the smaller and larger topologies.