Benchmarking Real-Time Database Synchronisation Architectures: REST Polling, WebSocket Push, and CockroachDB CDC
Este artigo apresenta um benchmark controlado comparando arquiteturas de polling REST, WebSocket push e CockroachDB CDC para sincronização de banco de dados em tempo real, revelando que, embora o WebSocket push ofereça a menor latência mediana e o polling REST proporcione atrasos limitados previsíveis, o CDC entrega medianas competitivas, mas sofre de latência de cauda significativa devido ao processamento em lote e incompatibilidades de protocolo específicas.
Artigo original sob licença CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo
No mundo do software moderno, há um desejo crescente por aplicações que pareçam viver no seu dispositivo, mesmo quando você não está conectado à internet. Essa abordagem, frequentemente chamada de software local-first, permite que você edite um documento ou atualize uma lista enquanto está offline, com as alterações aguardando para serem enviadas a um servidor central assim que a conexão retornar. O desafio reside no momento em que a conexão é restaurada: como o computador decide qual versão dos dados é a correta, e quão rápido ele pode atualizar o servidor central sem fazer o usuário esperar? Para que isso funcione de forma fluida, o sistema precisa de uma maneira confiável de ouvir novas informações e entregá-las instantaneamente. Se a atualização for muito lenta, o usuário sente um atraso (lag); se o sistema for muito complexo, ele consome a bateria ou trava. A questão central para os engenheiros é como construir esse mecanismo de escuta: o dispositivo deve perguntar constantemente ao servidor se algo mudou, o servidor deve anunciar as mudanças imediatamente ou o próprio banco de dados deve manter um registro contínuo de cada ação para ser lido posteriormente?
Um pesquisador do Instituto de Tecnologia de Kharagpur, na Índia, propôs-se a testar essas três estratégias comuns lado a lado para ver qual delas realmente apresenta o melhor desempenho em um ambiente controlado. O estudo comparou um método onde o cliente verifica atualizações em intervalos de tempo fixos, um método onde o servidor envia as mudanças instantaneamente através de uma conexão permanente e um método onde o banco de dados transmite um log de cada mudança para os assinantes. Para garantir um teste justo, o pesquisador construiu três sistemas separados que pareciam idênticos para o usuário, mas utilizavam engrenagens internas diferentes. Um sistema usava um banco de dados padrão com um loop simples de "verificação". Outro usava o mesmo banco de dados, mas adicionava um gatilho que disparava um sinal no momento em que uma mudança ocorria. O terceiro sistema utilizava um banco de dados distribuído diferente, projetado para transmitir seu próprio histórico. O objetivo era medir o tempo exato que uma alteração feita por um usuário levava para percorrer o sistema e aparecer na tela do ouvinte, testando desde um único usuário até cinquenta usuários escrevendo ao mesmo tempo.
Os resultados pintaram um quadro claro de como cada método se comporta sob pressão. O sistema que dependia do servidor anunciar as mudanças instantaneamente via uma conexão permanente provou ser o mais rápido. Nos melhores casos, uma mudança aparecia na tela do ouvinte em apenas dois milissegundos e, mesmo quando cinquenta pessoas escreviam simultaneamente, o atraso raramente excedia sessenta e três milissegundos. Este método manteve sua velocidade notavelmente constante, com as atualizações mais lentas ainda chegando em menos de um quarto de segundo. O método que dependia do cliente solicitar atualizações a cada cem milissegundos era previsível, porém mais lento. Como o cliente tinha que esperar sua vez de perguntar, o atraso médio era de cerca de sessenta milissegundos, mas nunca poderia ser mais rápido do que o tempo entre as verificações. Quando muitos usuários escreviam ao mesmo tempo, esse tempo de espera aumentava, elevando o atraso médio para mais de cem milissegundos. O sistema que utilizava o log interno de mudanças do banco de dados mostrou um desempenho misto. Embora a atualização típica chegasse rapidamente, muitas vezes em menos de um segundo, o sistema sofria com atrasos severos para as atualizações mais lentas. Ocasionalmente, uma mudança levava mais de dois segundos para chegar e, em alguns casos, o atraso estendia-se para mais de três segundos e meio.
O pesquisador descobriu que as atualizações mais lentas no sistema baseado em log não eram uma falha na ideia de registrar mudanças em si, mas um resultado de como o software específico estava conectado. O sistema utilizava uma solução de contorno para ler o log do banco de dados porque a ferramenta de conexão padrão não falava a linguagem do banco de dados corretamente. Essa solução de contorno exigia iniciar um novo processo toda vez que a conexão era interrompida, o que adicionava uma penalidade pesada de um a quatro segundos ao atraso. Sem esse obstáculo técnico específico, o método baseado em log poderia ter performado muito melhor, mas, neste teste, os longos atrasos o tornaram inadequado para aplicações onde os usuários esperam feedback instantâneo. O estudo também confirmou uma regra simples para o método de verificação: quanto mais tempo você espera entre as verificações, maior se torna o atraso médio. Se um sistema verifica a cada cinquenta milissegundos, o atraso médio é de cerca de trinta e seis milissegundos; se espera quinhentos milissegundos entre as verificações, o tempo de espera salta para mais de trezentos milissegundos.
Essas descobertas oferecem um guia prático para construir softwares que precisam permanecer sincronizados. Para aplicações onde a velocidade é crítica, como ferramentas de edição colaborativa onde usuários digitam juntos em tempo real, o método onde o servidor envia as mudanças instantaneamente é a escolha clara. Ele oferece o menor atraso e o desempenho mais consistente, mesmo quando muitas pessoas estão usando o sistema ao mesmo tempo. O método onde o cliente verifica atualizações em intervalos regulares é uma opção sólida para aplicações mais simples, onde um atraso de alguns centésimos de segundo é aceitável, ou onde manter a conexão aberta é difícil, como em dispositivos móveis tentando economizar bateria. O método que transmite o log do banco de dados é poderoso para mover grandes quantidades de dados ou criar backups, mas a implementação específica testada aqui foi lenta e imprevisível demais para uso interativo. O estudo conclui que, embora todos os três métodos funcionem, a melhor escolha depende inteiramente se a prioridade é a responsividade instantânea ou a simplicidade operacional.
Afogado em artigos na sua área?
Receba digests diários dos artigos mais recentes que correspondam às suas palavras-chave de pesquisa — com resumos técnicos, no seu idioma.