Elastic Scaling: Adding and Removing Zaris Servers Without Downtime

Capacity is never right for long. Traffic grows, a launch lands, a season ends — and the store you sized last quarter is either straining or half-idle. The question that decides whether that's a chore or a crisis is simple: can you change the size of a running store without taking it down?

For Zaris the answer is yes, with an important asymmetry that's worth being honest about up front. Scaling out — adding servers — is the easy, safe, lossless direction, and it happens live while the store keeps serving. Scaling in — removing servers — is also supported, but it's a deliberate, monitored operation because the data on a departing server has to go somewhere first.

This post walks both directions: growing a store with Add-ZrServer, shrinking it with Remove-ZrServer, why scale-in needs a drain, and where the web console fits.

The store has a desired shape

Underneath elastic scaling is one idea: a Zaris store's shape is described by a canonical StoreDefinition — the desired set of servers and partitions the store is supposed to have. It's the source of truth for what the cluster should look like, not a running tally of what it happens to look like right now.

Zaris runs under a supervisor model: the supervisor owns that canonical definition and continuously drives the running instances toward it. So scaling isn't a pile of manual steps you sequence by hand — you change the desired shape, and the supervisor reconciles the live cluster to match. Add-ZrServer and Remove-ZrServer are how an operator edits that desired shape, and the supervisor does the work of getting there.

Scaling out: live and lossless

Adding capacity is a single cmdlet. You point it at the store and give it the new server:

# Grow the store by adding a server to its definition
Add-ZrServer -Store orders -Server zaris-c.example.com:7861

# Check the resulting set
Get-ZrServer -Store orders

When you do this, the store repartitions live. The partitions redistribute so the new server picks up its share, data migrates to its new owners, and the store keeps serving reads and writes the entire time — there's no stop-the-world window. In testing we've grown a store from 6 partitions to 8 this way while it stayed online.

The guarantee that matters here: scale-out is lossless. No acknowledged write is lost during the migration. Data moves to the new owners, ownership cuts over, and a write the store told a client it committed is still there on the other side of the repartition. That's what makes adding capacity a routine operation — you can react to load by growing the store during traffic, not during a maintenance window.

Scaling in: drain, then remove

Removing a server is where the asymmetry shows up, and it's physics, not a limitation you can flag your way around. A server that's leaving is holding data — its share of the partitions. If it simply vanished, that data would vanish with it.

So scale-in is a drain-then-remove operation, not an instant kill. Before a departing server leaves, its partitions must migrate their data to the servers that are staying. Only once that data-plane drain is complete has the leaving server truly handed off everything it was responsible for, and only then is it safe for it to depart.

# Remove a server from the store's definition — this initiates the drain
Remove-ZrServer -Store orders -Server zaris-c.example.com:7861

Remove-ZrServer edits the desired shape to exclude that server, and the supervisor works the store toward the new definition by moving the departing server's partitions onto the remaining ones before it drops out. The mental model to hold is: capacity-up is instant and safe; capacity-down is a controlled migration. Treat a scale-in as a deliberate, monitored operation — kick it off, watch the drain progress, and confirm the data has landed on the remaining servers before you consider the server gone. Yanking a server without letting it drain is how you drop the data it held.

Watching it from the console

You don't have to run any of this blind. The web console has a Servers view that shows the current set of servers backing a store and lets you manage it. It's the natural place to:

• See the live set — which servers are in the store right now, versus the desired definition the supervisor is reconciling toward.
• Watch a scale-out land — confirm a newly-added server has picked up its partitions and is serving.
• Monitor a scale-in drain — follow a departing server's partitions migrating away before it leaves, so you know the drain is done rather than guessing.

For scale-in especially, that visibility is the point. A drain is a real data movement with a beginning and an end, and the Servers view is how you tell the difference.

The honest summary

Elastic scaling in Zaris comes down to editing a desired shape and letting the supervisor reconcile the running store to it:

• Scale-out (Add-ZrServer) is the easy, safe direction — live, repartitioning in place, and lossless. Grow into load whenever you need to.
• Scale-in (Remove-ZrServer) is supported and safe when you let it drain — the departing server's data migrates to the survivors first, so plan capacity-down as a deliberate, monitored operation rather than an instant kill.

Size for the traffic you have, not the traffic you feared, and change your mind later — up without ceremony, down with care.