Spook Systems Get Started
DocumentationBuild. Deploy. Operate.
DocsDeployment

Recommended Topologies

On this page 5 sections

QSCS clusters scale gracefully from a single node to a globally distributed mesh. The shape you pick depends on three things: where your origin server lives, where your users are, and how much failure tolerance you need. Below are four shapes that cover the common cases.

What every topology gives you Regardless of which shape you pick: a single encrypted ingress port per node (smaller attack surface), regionally local cache near your users (lower latency for cache hits), and zero shared-database / quorum-service dependencies (less moving parts to operate). HEADLESS protection applies at every node in every topology.

1. Single node

One QSCS process sits in front of one origin web server, on the same host or one network hop away. This is the simplest possible deployment, and a perfectly valid production setup if your site lives on one machine.

Host A QSCS :8080 Origin :80 users

Use when: small site, single host, want HEADLESS protection during transient origin failures. Benefit profile: resilience.

2. Master plus thin clients

One QSCS node hosts the origin (master). One or more additional QSCS nodes sit in different locations and proxy through the master.

Region A Origin Master (M) :8080 local users Region B Thin T₁ :8080 regional users Region C Thin T₂ :8080 regional users replicated cache + control plane · single encrypted port

Use when: users are spread across regions but the origin only exists in one place. Benefit profile: resilience + lower regional latency (region-local cache) + reduced complexity (each region needs only one open ingress port).

3. Hot-standby pair

A two-node cluster where one node is master and the other is a thin client co-located with, or attached to, a separate replica of your origin. Both nodes cache everything; if the master fails, you promote the thin client.

Primary Origin A Master (M) Standby Origin B Thin (T) replicated cache

Use when: you have two origin web servers and want manual failover with minimal user impact. Benefit profile: resilience (warm cache survives master loss) + simplicity (no separate replication service required; the cache is the replication channel).

4. Geo-distributed edge

One master, three or more thin clients spread across continents. All thin clients have the master's cache replicated; users hit the nearest edge.

Master (origin) :8080 Thin · EU :8080 EU users Thin · US :8080 US users Thin · AP :8080 AP users

Use when: you serve a global audience and the round-trip from the far side of the world to your origin matters. Benefit profile: dramatic latency reduction for cache hits (a user in Tokyo gets a response from a Tokyo-region edge in single-digit milliseconds rather than crossing the Pacific to hit your origin), plus the security and simplicity of a single encrypted port per node.

Choosing between them

NeedPick
Just want outage protection on one hostSingle node
Origin in one region, users in manyMaster + thin clients
Want quick manual failoverHot-standby pair
Truly global audienceGeo-distributed edge
Start simple, grow as needed Every topology above can be reached by adding nodes to a smaller one. You never have to plan the full thing up front; add a thin client, re-subscribe everyone, done. Adding a node never opens a new port and never introduces a new service to operate.
Need a hand with your deployment?Contact support ↗Back to top ↑