La previsibilidad es la dimensión oculta del rendimiento de la red
A quienes trabajan en redes de bajo nivel les gusta hablar de TPS, latencia y ancho de banda. Esos indicadores, claro, son importantes, pero solo responden a una pregunta: ¿qué tan rápido puede funcionar? —sin responder casi nunca a otra, más crucial: ¿es estable cuando funciona?
El protocolo Kadcast de Dusk me hizo replantear esto. No siguió la ruta habitual de la propagación aleatoria de rumores, sino que utilizó una red de cobertura estructurada para fijar la ruta de transmisión. El resultado no fue simplemente que fuera más rápido en una ocasión, sino que en cada ocasión fue más o menos igual de rápido. La latencia, de una distribución probabilística, pasó a ser una constante aproximada.
Esa diferencia, en cuanto llega a las capas superiores, tiene un impacto enorme. Una red impredecible equivale a decirle a los desarrolladores: no estoy seguro de ser confiable; tú te las arreglas. Así aparecen timeouts, reintentos, backoff exponencial, cachés de respaldo… toda una serie de complejidad que debería pertenecer a la capa inferior, pero que termina empujándose hacia la capa de aplicación. Y para colmo, suele ser justo el tipo de código más difícil de probar y el más propenso a errores.
Por eso, ahora prefiero definir el rendimiento así: una buena red no hace que los desarrolladores escriban código más rápido, sino que les permite escribir mucho menos código que, en realidad, no debería existir.
Esto es especialmente letal en el ámbito financiero. En los sistemas de trading, lo más caro no es la máquina: es la carga cognitiva. Cuando tu capacidad mental está ocupada con «¿y si la red tiembla?», ya no puedes concentrarte en los aspectos que realmente generan valor, como la lógica de emparejamiento y las estrategias de control de riesgos. El mayor valor de la previsibilidad es que permite a los desarrolladores eliminar suposiciones del propio código.
La mejor infraestructura es aquella que, una vez que la despliegas, casi te olvidas de que sigue ejecutándose.
@Dusk #dusk $DUSK
A quienes trabajan en redes de bajo nivel les gusta hablar de TPS, latencia y ancho de banda. Esos indicadores, claro, son importantes, pero solo responden a una pregunta: ¿qué tan rápido puede funcionar? —sin responder casi nunca a otra, más crucial: ¿es estable cuando funciona?
El protocolo Kadcast de Dusk me hizo replantear esto. No siguió la ruta habitual de la propagación aleatoria de rumores, sino que utilizó una red de cobertura estructurada para fijar la ruta de transmisión. El resultado no fue simplemente que fuera más rápido en una ocasión, sino que en cada ocasión fue más o menos igual de rápido. La latencia, de una distribución probabilística, pasó a ser una constante aproximada.
Esa diferencia, en cuanto llega a las capas superiores, tiene un impacto enorme. Una red impredecible equivale a decirle a los desarrolladores: no estoy seguro de ser confiable; tú te las arreglas. Así aparecen timeouts, reintentos, backoff exponencial, cachés de respaldo… toda una serie de complejidad que debería pertenecer a la capa inferior, pero que termina empujándose hacia la capa de aplicación. Y para colmo, suele ser justo el tipo de código más difícil de probar y el más propenso a errores.
Por eso, ahora prefiero definir el rendimiento así: una buena red no hace que los desarrolladores escriban código más rápido, sino que les permite escribir mucho menos código que, en realidad, no debería existir.
Esto es especialmente letal en el ámbito financiero. En los sistemas de trading, lo más caro no es la máquina: es la carga cognitiva. Cuando tu capacidad mental está ocupada con «¿y si la red tiembla?», ya no puedes concentrarte en los aspectos que realmente generan valor, como la lógica de emparejamiento y las estrategias de control de riesgos. El mayor valor de la previsibilidad es que permite a los desarrolladores eliminar suposiciones del propio código.
La mejor infraestructura es aquella que, una vez que la despliegas, casi te olvidas de que sigue ejecutándose.
@Dusk #dusk $DUSK