Operate Cheetah
Operating Cheetah means operating a distributed application boundary: client connections, returned HTTP data, product APIs, shared coordination, retained evidence, administrative inspection, and the external systems that actions can affect.
A preset can reject unsafe component choices, but it cannot see the deployed proxy, identity provider, secret store, storage policy, or incident workflow. Production confidence comes from testing the complete path through those systems.
Start from the responsibility that is under pressure
WebSocket hosts own long-lived client connections and direct socket delivery. REST hosts accept progress, results, errors, events, and state. Application hosts create commands and run product workflows. A small deployment may put all three roles in one process. A larger deployment can scale each role independently over compatible Redis-backed components.
The separation also shapes failure. A socket remains owned by one WebSocket process. A pending waiter remains in the application process that created it. Retained history can survive either process when its backing store remains available, but it does not migrate the original call stack.
The operating path
Secure the complete boundary covers transport truth, client and operator identity, limits, secrets, tenancy, and the parts no preset can supply.
Deploy and scale maps WebSocket, REST, application, and observation loads to their roles and states what Redis coordination does and does not guarantee.
Bound capacity and retain evidence separates live coordination, delivery, history, spill storage, product records, tracing, and audit so each receives an honest limit and lifecycle.
Observe and diagnose combines traces, diagnostics, retained messages, and product evidence into a practical investigation sequence.
Recover from failures distinguishes reconnect, runtime replacement, missed notifications, application-process failure, and unknown external outcomes.
Readiness, shutdown, and upgrades treats lifecycle and compatibility as operational features rather than process-manager details.
Establish a production acceptance journey
Before exposure, test one command through the actual load balancer, certificates, identity providers, server roles, storage, and client environment. Confirm an allowed action, a denied action, returned-data authentication, history visibility, trace continuity, tenant isolation where applicable, and cleanup after interruption.
This catches errors that isolated health checks miss: an internal REST URL advertised to an external client, a trusted-forwarding mistake, a diagnostic route without the intended admin gate, or a result that is stored but never wakes its caller.