Gridmatic es una plataforma de trading multi-tenant para prop firms operada por Block Research. Corre runtimes de señales en Python aislados para decenas de traders, transmite OHLCV en vivo a un datafeed nativo de TradingView y ejecuta órdenes contra Kraken en producción.
La plataforma de este caso de estudio, contada por la persona que la opera cada día. Dos minutos de Emilio, en sus propias palabras.
Cada cambio de estrategia implicaba redesplegar todo el sistema, así que cualquier commit malo amenazaba a todos los traders de la plataforma.
Los runtimes estaban compartidos, así que una estrategia atascada dejaba sin CPU, memoria y atención al resto a las 3 de la madrugada.
No había forma limpia de parar, inspeccionar o auditar un runtime concreto. Los traders debuggeaban en producción con console.log.
Timo y el equipo de Block Research ya habían tropezado con los mismos problemas construyendo vyn premium y SignalPipe. Reconstruimos el stack como lo querrían los operadores, no como lo entregaría una agencia.
El diagrama siguiente muestra el camino que recorre una señal desde los datos de mercado hasta la ejecución de la orden. Ninguna capa existe por moda.
Handlers REST y WebSocket personalizados sirven barras OHLCV en vivo a un gráfico nativo de TradingView, para que los traders conserven la UX que ya conocen.
Un pod de Kubernetes por runtime. Cada estrategia vive en su propio contenedor, con su CPU, su memoria y su comportamiento ante crash-loops. Parar, reiniciar y sustituir son operaciones de un solo pod.
Hypertables dimensionadas para millones de señales. Las consultas por rango temporal responden en decenas de milisegundos, así el selector de runtimes y la escalera de posiciones se sienten instantáneos.
Vista de operador: mapa de calor de señales, selector de runtimes, escalera de posiciones, logs de pods. Construido con React + Vite, contra las mismas APIs que consumen los runtimes.
Operadores e ingenieros acceden al cluster por una VPN WireGuard privada. Sin SSH público, sin plano admin expuesto, sin intentos de brute-force sorpresa.
Cinco servidores dedicados en Alemania. Residencia de datos europea y aproximadamente un tercio del coste del equivalente en AWS con el mismo margen.
Capturas en camino, pídeselas a Timo para la build actual.
Cada trader corre en su propio pod. Un crash en un runtime no se propaga. Parar, reiniciar y los límites de recursos son nativos, no parches.
Las queries por rango sobre millones de señales responden en milisegundos. La misma base de datos alimenta el histórico de runtimes, el mapa de calor y las vistas de analytics internas.
Los traders ya leen gráficos de TradingView. Construimos un datafeed adapter propio para encontrarlos donde están, en vez de obligarlos a aprender otra librería de charting.
Residencia de datos europea, aproximadamente un tercio del equivalente AWS para el mismo margen, y un plano privado WireGuard para que los operadores no toquen SSH público.
Una demo sobrevive a una reunión. Un sistema en producción sobrevive a un trader pegando la config equivocada a las 4 de la mañana. Cada decisión en Gridmatic se tomó pensando en el segundo caso.
Cuando hay capital en vivo dependiendo de un datafeed, la latencia p95 no es una métrica bonita. Dirige la arquitectura: qué base de datos, qué broker, qué región, qué ruta de red.
No añadimos logs y dashboards después del lanzamiento. Loki, Grafana, logging estructurado y runbooks están cableados en el primer deploy, para diagnosticar incidentes en vivo sin adivinar.
Hacemos una llamada corta de discovery, mapeamos la plataforma que necesitas y la cotizamos como un build de alcance fijo. Sin pitch deck, sin trampa de retainer.