DocumentationBuild. Deploy. Operate.
DocsConcepts

Master & Thin Clients

On this page 3 sections

In any cluster of two or more nodes, exactly one node is the master. The rest are thin clients. This is not a database leader-election in the traditional sense, there is no consensus protocol, no quorum, no Raft term. The master is simply the node that holds the real backend addresses for the cluster's origins.

What each role does

MasterThin client
Origin backendReal address (e.g. 127.0.0.1:80)Pre-rewritten to <master>:8080
Reaches origin?Yes, directNo, through master
Caches?YesYes, independently
HEADLESS triggers when…Origin failsMaster fails
Number per clusterExactly oneZero or more

Why this design

Treating only the master as having "real" upstream connectivity means thin clients can be placed anywhere, a far region, a partner's network, a small embedded device, without needing direct line-of-sight to the origin web server. The master is the single point that talks to the origin, and the thin clients form a transparent fan-out around it.

Three concrete benefits fall out of this design:

  • Latency. Each thin client serves its region's traffic from a local cache. Users in that region get cache hits without ever crossing to the master, which is often on a different continent.
  • Security. The only network port the thin client needs open to the world is its own public port (typically fronted by your TLS terminator). Replication, cache pulls, and control-plane sync between thin and master all flow over a single encrypted port, the same port that serves end users. There is no separate "replication port" to firewall, no admin channel to secure separately. Smaller surface area, fewer rules to forget.
  • Simplicity. No shared database, no quorum service, no message broker. Adding capacity is "install the package, subscribe, restart", that is the entire runbook.

Each thin client maintains its own cache for the master. If the master itself becomes unreachable, the thin client serves HEADLESS responses locally from that cache. So you get two layers of resilience:

When the origin is unreachable Origin unreachable Master serves HEADLESS from cache Thin client sees a normal 200 response users When the master is unreachable Master unreachable Thin client serves HEADLESS from its own local cache users

Promoting a different node to master

From the control panel: open your cluster, click the ☆ icon next to the node you want to promote. The icon turns into a gold ★ and the API responds. On each cluster member, re-subscribe and restart:

sudo qscs subscribe domain <cluster-tag>
sudo systemctl restart qscs

Old master becomes a thin client; new master picks up real backend addresses.

Master selection is a deployment choice The master should be the node that can reach your origin web server. If your origin lives at 127.0.0.1:80 on one specific host, that host must be the master. Promoting a node that has no path to the origin will leave the cluster unable to fetch fresh content.
Need a hand with your deployment?Contact support ↗Back to top ↑