Grow from the first proof
The first connected action is deliberately small, but its concepts are intended to survive as the product grows. Growth should replace implementations and separate responsibilities when the workload demands it; it should not require product code to adopt a different meaning for actions, clients, results, or authority.
The stages describe coherent deployment shapes, not mandatory milestones. A useful product may stay in one shape indefinitely.
Add product behavior before adding infrastructure
Replace example_info with an action that has product value. Keep the handler close to the environment that owns the capability: browser-page behavior belongs in the browser layers; filesystem or process behavior belongs in a console or custom machine client. Define the parameters, result, error cases, and authority requirements as part of the action contract.
The application then decides which stable client or context should receive that action. It can interpret progress and results in domain terms and store the business facts it needs. Cheetah history remains evidence about the distributed exchange, not a substitute for the product's authoritative database.
Add another client environment
The shared runtime makes browser, console, cooperative web, and custom clients recognizable as members of the same system. They still expose different capabilities and trust boundaries. Add a platform package and its handlers; do not make a console pretend to be a browser or give a page the authority of an extension.
A logical client identity represents the stable address known to the product. A runtime instance represents the current process or service-worker lifetime. Reconnection can replace the route while preserving the logical address. Once a send attempt begins, Cheetah binds it to the actual instance making that attempt so an acknowledgement from a replacement runtime cannot satisfy the earlier command.
Keep the three server roles together while that is enough
A single process can host the application-facing, WebSocket, and returned-data roles using one in-memory component family. This is a real deployment shape for a small application. It preserves the semantic separation between asking for work, owning a connection, and accepting returned evidence without requiring distributed coordination.
Its limit is process scope. Presence, pending correlation, deduplication, and ordinary in-memory history disappear on restart and are not visible to a second host. Plan recovery in terms of current client truth, retained external truth, and product state rather than trying to serialize every transient object.
Separate roles when their pressure differs
Long-lived WebSocket connections, incoming HTTP results, and product request handling have different scaling profiles. Redis-backed components let independently running roles share routes, durable logical-client command mailboxes, pending correlation metadata, notifications, history, deduplication, contexts, and selected topology state.
This is not a single-process preset with a different URL. Distribution introduces Redis availability and persistence, unique node identity, listener ownership, shared payload storage, rollout compatibility, observability, shutdown coordination, and incident response. Mailbox notifications are disposable wake-up hints: reconnect checks and periodic sweeps find admitted work if a hint is lost. Response notifications are also signals, so readers consult retained history after a missed notification. Neither facility replaces a durable product job queue.
Add tenancy as an end-to-end scope
If several mutually untrusted tenants share infrastructure, the tenant principal must be derived at ingress and preserved through registry, dispatch, correlation, history, and application access. Cheetah's shared-tenancy composition validates compatible components and returns a restricted application surface so callers cannot escape their tenant by supplying an arbitrary user ID.
Shared-tenancy support does not create account provisioning, billing, organization policy, or a complete hosted-service boundary. Those remain product and platform responsibilities. It also accepts a deliberately restricted facility set; consult the shared-tenancy reference before adding tracing, payload storage, policy, parsers, or derived views to that mode.
Add optional facilities deliberately
Tracing, diagnostics, dashboards, browser capture, parser definitions, worker/context coordination, derived views, UI components, and site relays can be added at defined seams. They are not silently enabled by a server preset. Each facility has its own data sensitivity, storage, authentication, lifecycle, maturity, and tenancy considerations.
The next sections explain the system before showing how to compose and extend it. This is the point to continue either by mental model or by implementation task:
- Understand Cheetah for ownership, identity, commands, and recovery;
- Build and extend for server composition and client actions;
- Operate for security, scaling, diagnostics, and failure handling.