Gridmatic ist eine Multi-Tenant-Trading-Plattform für Prop Firms, betrieben von Block Research. Sie betreibt isolierte Python-Signal-Runtimes für Dutzende Trader, streamt Live-OHLCV in einen browser-nativen TradingView-Datafeed und führt Orders gegen Kraken in Produktion aus.
Die Plattform aus dieser Case Study, eingeordnet von der Person, die sie jeden Tag betreibt. Zwei Minuten von Emilio, in seinen eigenen Worten.
Jede Strategieänderung hieß, das ganze System neu zu deployen. Ein schlechter Commit gefährdete alle Trader auf der Plattform gleichzeitig.
Runtimes waren geteilt. Eine festgefahrene Strategie hat allen anderen um 3 Uhr nachts CPU, RAM und Aufmerksamkeit weggenommen.
Es gab keinen sauberen Weg, eine einzelne Runtime zu stoppen, zu inspizieren oder zu auditieren. Trader haben in Produktion mit console.log debuggt.
Timo und das Block-Research-Team sind bei vyn premium und SignalPipe schon in dieselben Probleme gelaufen. Wir haben den Stack so neu gebaut, wie ihn Operatoren wollen, nicht wie ihn eine Agentur ausliefern würde.
Das folgende Diagramm zeigt den Weg, den ein Signal von den Marktdaten bis zur Orderausführung nimmt. Keine Schicht ist aus Mode eingebaut.
Eigene REST- und WebSocket-Handler liefern Live-OHLCV-Bars an einen browser-nativen TradingView-Chart. Trader behalten die Charting-UX, die sie schon kennen.
Ein Kubernetes-Pod pro Runtime. Jede Strategie lebt in ihrem eigenen Container, mit eigener CPU, eigenem RAM und eigenem Crash-Loop-Verhalten. Stoppen, Neustart, Ersatz sind Einzel-Pod-Operationen.
Hypertables, dimensioniert für Millionen Signale. Zeitbereichs-Queries antworten in zweistelligen Millisekunden, also fühlen sich Runtime-Switcher und Positions-Ladder sofort an.
Operator-Ansicht: Signal-Heatmap, Runtime-Switcher, Positions-Ladder, Pod-Logs. Mit React + Vite gegen dieselben APIs gebaut, die die Runtimes konsumieren.
Operatoren und Engineers erreichen das Cluster über ein privates WireGuard-VPN. Kein öffentliches SSH, keine offene Admin-Ebene, keine überraschenden Brute-Force-Versuche.
Fünf dedizierte Server in Deutschland. Europäische Datenresidenz und ungefähr ein Drittel der Kosten des AWS-Pendants bei gleichem Headroom.
Screenshots folgen, frag Timo für den aktuellen Build.
Jeder Trader läuft in seinem eigenen Pod. Ein Crash in einer Runtime kaskadiert nicht. Stop, Restart und Ressourcengrenzen sind nativ, nicht nachträglich drangeklebt.
Bereichs-Queries über Millionen Signale antworten in Millisekunden. Dieselbe Datenbank trägt Runtime-Historie, Signal-Heatmap und interne Analytics-Views.
Trader lesen ohnehin TradingView-Charts. Wir haben einen eigenen Datafeed-Adapter gebaut, damit wir sie dort abholen, wo sie sind, statt sie eine neue Charting-Bibliothek lernen zu lassen.
Europäische Datenresidenz, rund ein Drittel der AWS-Kosten für denselben Headroom und eine private WireGuard-Ebene, damit Operatoren kein öffentliches SSH brauchen.
Eine Demo überlebt ein Meeting. Ein Produktionssystem überlebt einen Trader, der um 4 Uhr nachts die falsche Config einfügt. Jede Designentscheidung in Gridmatic wurde für den zweiten Fall getroffen.
Wenn echtes Kapital an einem Datafeed hängt, ist p95-Latenz keine schöne Kennzahl. Sie steuert Architektur: Welche Datenbank, welcher Broker, welche Region, welcher Netzwerkpfad.
Wir kleben Logs und Dashboards nicht nach dem Launch an. Loki, Grafana, strukturiertes Logging und Runbooks sind im ersten Deploy verdrahtet, damit wir Live-Probleme ohne Raten diagnostizieren.
Wir machen einen kurzen Discovery-Call, mappen die Plattform, die ihr braucht, und kalkulieren sie als Festpreis-Build. Kein Sales-Deck, keine Retainer-Falle.