Ticketing Server Deployment

Environment Variables ​

Every entry in ticketing.toml (optional) can also be set via an environment variable. Precedence is environment variable > ticketing.toml > default, and both keys and boolean values are case-insensitive. The Docker image is scratch-based, so injecting config via environment variables is the default (to use a config file instead, mount it and point CONFIG at its path).

Single vs. Cluster ​

• Single node: without [cluster] (or CLUSTER_*), the node runs standalone. Fastest, but there's a brief blip on restart, and state is in-memory so it's lost on restart (lease is the safety net).
• Cluster (zero-downtime): at least 2 nodes. Each node has the same CLUSTER_PEERS (in priority order) and its own CLUSTER_SELF pointing to itself. Among the live nodes, the one with the highest priority becomes active, and the rest become standbys receiving real-time replication. For details, see How It Works and Protocol — Server ↔ Server.

Kubernetes cluster deployments use a StatefulSet + headless Service. Give each pod a stable DNS name (ticketing-0.ticketing…, ticketing-1.ticketing…), put those names into CLUSTER_PEERS in priority order, and auto-inject each pod's CLUSTER_SELF via the downward API (metadata.name).

Zero-Downtime Restart (Rolling) ​

1. Restart the standbys first, one at a time (the active keeps serving throughout).
2. Finally, shut down the active (Ctrl+C) — a handoff promotes a standby and clients move over.
3. Bringing the old active back up rejoins it as a standby of the current active (no automatic failback).

Reference ​

• Image: sarolab/ticketing · Github: saro-lab/ticketing
• Register all node addresses with the client (broker) so it switches over automatically on failure. See Libraries for language-specific usage.