The standard playbook for shipping without downtime — blue/green, rolling, canary — was written for stateless request handlers. You start new instances, drain the old ones, and the load balancer hides the seam. None of that transfers cleanly to a process that is holding working orders and a position it must not lose track of.
Why can’t I just do a rolling deploy?
Because "drain the old instance" has no meaning when the old instance owns state that lives longer than any request. A trading process typically holds three things the deployment has to reason about: the current position, the set of live orders at the venue, and the session with the venue itself, which is often sequence-numbered and does not tolerate two claimants.
If you start a second instance and both connect, you now have two systems that each believe they own the position. If you stop the first and start the second, there is a window where nobody is watching the orders that are still live at the exchange. Neither is acceptable, so most desks default to the only option that is obviously safe: deploy at the weekend.
Separate the parts that hold state from the parts that do not
The way out is architectural rather than procedural. Most of a trading stack does not hold trading state at all: market-data normalisers, analytics, dashboards, reporting, most of the risk calculations. Those can and should deploy like any web service, continuously, with no ceremony.
What remains is a small stateful core — usually the order manager and the venue sessions. Shrinking that core is the actual work. Teams that can deploy on a Tuesday almost always got there by making the stateful part small and boring, not by finding a cleverer deployment tool.
Externalise the state you cannot avoid
Once the core is small, the next move is to stop keeping its state in memory. Position and order state live in a store the process reads on start and writes on every transition; the process itself becomes close to disposable. Restarting it is then a recovery exercise the system already has to be good at, because it has to survive a crash anyway.
This has a pleasant side effect: you can no longer have a recovery path that only gets exercised during incidents. If every deploy is a restart, then every deploy tests recovery. The code path that used to be the scariest becomes the most-travelled one.
Handing over the venue session
The remaining hard part is the session. Some venues support multiple concurrent sessions per participant, which makes handover trivial: the new process connects, confirms it can see the working orders, and the old one logs out. Where the venue permits only one, the handover has to be a coordinated gap — measured in hundreds of milliseconds, taken deliberately at a quiet moment, with a supervisor that will re-establish the old process if the new one does not confirm within its budget.
A deliberate 400ms gap at 11:14 on a Tuesday is a smaller risk than a batched six-week release at the weekend, but it only feels that way once the handover is automated and has run a few hundred times. Rehearsal is what turns it from a stunt into a procedure.
Cancel-on-disconnect is not a strategy
Most venues offer cancel-on-disconnect, and it is worth having enabled as a backstop. It is not a deployment mechanism. Relying on it means every deploy pulls your quotes, which is both a trading cost and a signal to anyone watching the book. Use it as the thing that saves you when the handover fails, not as the handover.
The rollback question
Every deployment plan should be judged on its rollback, not its rollout. The question to ask before shipping is: if this build starts behaving strangely in twenty minutes, what is the sequence that puts the old one back, who runs it, and has it been rehearsed this quarter? If the honest answer involves improvisation, the deployment is not ready regardless of how well the tests went.