Gridmatic is a multi-tenant prop-firm trading platform operated by Block Research. It runs isolated Python signal runtimes for dozens of traders, streams live OHLCV into a browser-native TradingView datafeed, and executes orders against Kraken in production.
The platform this case study covers, reviewed by the person who runs it every day. Two minutes from Emilio, in his own words.
Every new strategy change meant redeploying the whole system, so any bad commit threatened every trader on the platform.
Runtimes were shared, so one stuck strategy starved everyone else of CPU, memory, and attention at 3am.
There was no clean way to stop, inspect, or audit a single runtime. Traders were debugging in production with console.log.
Timo and the Block Research team had already run into the same problems building vyn premium and SignalPipe. We rebuilt the stack the way operators would want it, not the way a dev shop would deliver it.
The diagram below is the path one signal takes from market data to order fill. No layer exists for fashion.
Custom REST and WebSocket handlers serve live OHLCV bars to a browser-native TradingView chart, so traders keep the charting UX they already know.
One Kubernetes pod per runtime. Each strategy lives in its own container, with its own CPU, memory, and crash-loop behaviour. Stop, restart, and replace are single-pod operations.
Hypertables sized for millions of signals. Time-range queries answer in tens of milliseconds, so the runtime switcher and the position ladder feel instant.
Operator view: signal heatmap, runtime switcher, position ladder, pod logs. Built with React + Vite, wired to the same APIs the runtimes consume.
Operators and engineers reach the cluster over a private WireGuard VPN. No public SSH, no exposed admin plane, no surprise brute-force attempts.
Five dedicated servers in Germany. European data residency, and roughly one-third of the cost of the AWS equivalent at the same headroom.
Screenshots coming, ask Timo for the current build.
Every trader runs in their own pod. A crash in one runtime never cascades. Stop, restart, and resource limits are native, not bolted on.
Range queries on millions of signals answer in milliseconds. The same database powers the runtime history, the signal heatmap, and the internal analytics views.
Traders already read TradingView charts. We built a custom datafeed adapter so we meet them where they are, instead of making them learn a new chart library.
European data residency, roughly one-third of the AWS equivalent for the same headroom, and a private WireGuard plane so operators never touch public SSH.
A demo survives one meeting. A production system survives a trader pasting the wrong config at 4am. Every design decision in Gridmatic was picked for the second case.
When live capital depends on a datafeed, p95 latency is not a nice-to-have metric. It drives architecture: pick the database, pick the broker, pick the region, pick the network path.
We do not bolt on logs and dashboards after launch. Loki, Grafana, structured logging, and runbooks are scaffolded into the first deploy, so we can diagnose live issues without guessing.
We run a short discovery call, map the platform you need, and quote it as a fixed-scope build. No sales deck, no retainer trap.