A previsibilidade é a dimensão oculta do desempenho da rede
Quem trabalha com redes de baixo nível gosta de conversar sobre TPS, latência e largura de banda. Essas métricas são, claro, importantes, mas elas respondem apenas uma pergunta: quão rápido consegue rodar? — e raramente respondem outra, ainda mais crucial: durante a execução, a rede fica estável ou não?
O protocolo Kadcast do Dusk me fez repensar isso. Ele não segue as rotas comuns de propagação de boatos aleatórios; em vez disso, usa uma rede de cobertura estruturada para fixar os caminhos de transmissão. O resultado não é apenas ficar mais rápido em uma única vez, mas manter praticamente a mesma velocidade a cada execução. A latência deixa de ser uma distribuição probabilística e passa a se aproximar de um valor constante.
Essa diferença, assim que chega às camadas superiores, causa um impacto enorme. Uma rede imprevisível é como dizer aos desenvolvedores: eu posso não ser confiável, vocês que se virem. Assim surgem timeouts, novas tentativas, backoff exponencial, cache de fallback... uma série de complexidades que deveriam ficar na camada de baixo é empurrada para a aplicação. E pior: muitas vezes esse código é justamente a parte mais difícil de testar e a mais propensa a bugs.
Por isso, hoje eu prefiro definir desempenho assim: uma boa rede não faz o desenvolvedor escrever códigos mais rápidos; faz com que ele escreva menos uma grande quantidade de código que nem deveria existir.
Isso é especialmente fatal em cenários financeiros. No sistema de transações, o mais caro não é a máquina — é a carga cognitiva: quando sua capacidade mental é tomada por perguntas como “será que a rede vai oscilar e tomar conta de tudo?”, você não consegue se concentrar na lógica de matching e nas estratégias de gestão de risco, que são onde realmente se cria valor. O maior valor da previsibilidade é permitir que o desenvolvedor remova suposições do código.
A melhor infraestrutura é aquela que, depois que você a implanta, quase dá para esquecer que ainda está em execução.
@Dusk #dusk $DUSK
Quem trabalha com redes de baixo nível gosta de conversar sobre TPS, latência e largura de banda. Essas métricas são, claro, importantes, mas elas respondem apenas uma pergunta: quão rápido consegue rodar? — e raramente respondem outra, ainda mais crucial: durante a execução, a rede fica estável ou não?
O protocolo Kadcast do Dusk me fez repensar isso. Ele não segue as rotas comuns de propagação de boatos aleatórios; em vez disso, usa uma rede de cobertura estruturada para fixar os caminhos de transmissão. O resultado não é apenas ficar mais rápido em uma única vez, mas manter praticamente a mesma velocidade a cada execução. A latência deixa de ser uma distribuição probabilística e passa a se aproximar de um valor constante.
Essa diferença, assim que chega às camadas superiores, causa um impacto enorme. Uma rede imprevisível é como dizer aos desenvolvedores: eu posso não ser confiável, vocês que se virem. Assim surgem timeouts, novas tentativas, backoff exponencial, cache de fallback... uma série de complexidades que deveriam ficar na camada de baixo é empurrada para a aplicação. E pior: muitas vezes esse código é justamente a parte mais difícil de testar e a mais propensa a bugs.
Por isso, hoje eu prefiro definir desempenho assim: uma boa rede não faz o desenvolvedor escrever códigos mais rápidos; faz com que ele escreva menos uma grande quantidade de código que nem deveria existir.
Isso é especialmente fatal em cenários financeiros. No sistema de transações, o mais caro não é a máquina — é a carga cognitiva: quando sua capacidade mental é tomada por perguntas como “será que a rede vai oscilar e tomar conta de tudo?”, você não consegue se concentrar na lógica de matching e nas estratégias de gestão de risco, que são onde realmente se cria valor. O maior valor da previsibilidade é permitir que o desenvolvedor remova suposições do código.
A melhor infraestrutura é aquela que, depois que você a implanta, quase dá para esquecer que ainda está em execução.
@Dusk #dusk $DUSK