Zaltev

Automated trading products fail in boring ways. One user's strategy crashes and takes the shared process down with it. A broker connection drops overnight and nobody notices until the morning. A backtest promises one edge and the live engine trades a subtly different one. Money moves on a code path nobody tested.

Zaltev needed to run many users' engines against a real broker, continuously, with money on the line — and needed the operators to know something was wrong before the customers did.

We treated isolation and observability as product requirements, not infrastructure chores. Each user's engine runs in its own OS subprocess so a bad strategy, a wedged broker socket, or a memory leak is contained to one account and can be killed and respawned without touching anyone else.

The second principle was a single source of truth for anything that could disagree with itself: one strategy module shared by the live engine and the backtester, one alert computation shared by the operations dashboard and the Telegram alerter, one risk gate that every trade must pass through.

The platform ships as eleven containerised services behind Caddy: two React SPAs (a user dashboard and an admin console), a FastAPI backend on multiple workers, an engine worker that owns the fleet, an ops-collector sidecar, two Telegram bots, PostgreSQL, and Redis.

Users onboard, connect their broker, pick a plan, and start an engine. Operators get a single Mission Control view spanning infrastructure health, per-user engine state, signal integrity, revenue, and support tickets — with revenue stripped out for roles that have no business seeing it.