Database and Web App Placement Constraint
This principle warrants its own section because it is one of the most overlooked architectural constraints in multi-server Kasm deployments, and violations are typically discovered only after deployment when platform performance is already degraded.
The constraint is simple and absolute:
Every Web App node must be provisioned as physically and topologically close to the database as possible.
Close means same data center, same availability zone, or same cloud region: any configuration where the round-trip network latency between a Web App node and the database server is measured in single-digit milliseconds, not tens or hundreds of milliseconds.
Why the Latency Math Matters
The kasm_api and kasm_manager services issue many sequential, blocking database queries during normal operations. Sequential and blocking are the critical terms here. These are not fire-and-forget asynchronous calls. They are synchronous calls where each step in a workflow waits for the previous database response before proceeding.
Consider a user launching a workspace in a deployment where the Web App is in US-East and the database is in APJ-West. The round-trip latency between those regions is approximately 100 to 150 milliseconds. If a single workspace launch requires ten sequential database queries, the database interaction alone contributes 1,000 to 1,500 milliseconds of latency to that user's session startup.
At enterprise scale with many concurrent workspace launches, this compounding effect degrades the entire control plane for all users across all zones simultaneously. The degradation is not local to the users who are geographically distant from the database: it affects every user whose session creation happens to be processed during a period of high database query load.
Control plane latency caused by distant database placement does not manifest as a localized problem affecting specific users. It manifests as systemic platform sluggishness affecting all users simultaneously. Symptoms including slow session launches, slow admin UI responses, and timeout errors can be attributed to many causes. Administrators who observe these symptoms should verify database round-trip latency before investigating other causes.
Dedication Proxy Role for Geographic Distribution
The instinctive response to serving remote users is to place Web App nodes closer to those users. This instinct is wrong in the Kasm architecture.
The control plane must remain co-located with the database. The correct architectural response to serving remote users is to place Dedicated Proxy nodes in each region.
Dedicated Proxy nodes have no database dependency. They run a single service, kasm_proxy, which relays session traffic between the user's browser and the Agent. The proxy's only interaction with the control plane is a single Upstream Auth HTTPS call at session connect time to validate the session token. For a trans-continental path, this one-time call adds approximately 100 to 200 milliseconds at connection establishment. After that single validation, the session streams entirely within the remote region at local latency for the entire duration of the session.
The Practical Implication for Capacity Planning
The database co-location constraint means Web App nodes and the database should be treated as a single logical unit from a placement perspective, even when they run on separate physical servers.
In cloud deployments, this means both should be in the same availability zone rather than simply the same region:
| Network Path | Typical Round-Trip Latency |
|---|---|
| Intra-availability-zone | Sub-millisecond |
| Intra-region, cross-availability-zone | 1 to 5 milliseconds |
| Cross-region (even nearby regions) | Tens of milliseconds or higher |
Single-digit millisecond round-trip latency between the Web App and the database is not an aspiration. It is the operating condition the control plane was designed for. Deployments that operate outside this condition will experience control plane performance that degrades predictably with load, in a way that cannot be remediated by adding more Web App nodes or increasing database resources.
The database co-location constraint is one of the most reliable leading indicators of production success in enterprise Kasm deployments. Organizations that plan for it before deployment avoid a class of performance problems that are expensive to diagnose and require infrastructure changes to resolve.
This article is part of the Kasm Workspaces Reference Architecture Explanation Series.