Discord: Como Armazenar Trilhões de Mensagens: Teardown da Migração Cassandra → ScyllaDB

O Discord adotou Apache Cassandra cedo, e a escolha fazia sentido: modelo de dados wide-column, escalabilidade horizontal sem ponto único de falha, e um ecossistema maduro. Para uma plataforma de mensagens onde cada servidor do Discord (guild) tem canais, e cada canal tem um histórico de mensagens que precisa ser lido de forma eficiente por timestamp, o modelo de partição do Cassandra é quase perfeito na teoria. Você particiona por (channel_id, bucket) e clusteriza por message_id (Snowflake, monotonicamente crescente), o que dá leituras de intervalo de tempo em uma única partição. Elegante.

O problema não era o modelo de dados. Era a JVM.

O Cassandra roda na JVM e, com heaps grandes, necessários para manter índices e caches em memória para trilhões de mensagens, o garbage collector se torna o inimigo. Pausas de GC de segundos não são hipotéticas nessa escala; são rotineiras. O Discord reportou latências de p99 e p999 completamente imprevisíveis, com picos que chegavam a segundos em operações que deveriam levar milissegundos. Em uma plataforma de comunicação em tempo real, isso é perceptível. Usuários veem o histórico de mensagens demorar para carregar. A experiência quebra.

Há também o problema de compactação. O Cassandra usa LSM trees (Log-Structured Merge-tree) internamente, e o processo de compactação, necessário para manter a performance de leitura ao longo do tempo, compete com operações de produção por I/O e CPU. Em clusters grandes e sob carga contínua, janelas de compactação se tornam eventos de risco operacional. A equipe do Discord descreveu nós quentes (hot nodes) que causavam pressão de cauda no cluster inteiro, porque o Cassandra não tem isolamento de recursos por operação, um nó lento contamina o percentil de latência do cluster.

A alternativa óbvia seria tunar o GC, usar ZGC ou Shenandoah, reduzir o heap, fragmentar os clusters. A equipe tentou essas abordagens. O problema é que elas compram tempo, não resolvem a causa raiz: você está rodando um banco de dados de missão crítica em cima de um runtime com coleta de lixo não-determinística. Em algum ponto, a engenharia de tuning vira dívida técnica acumulada, e a relação custo-benefício inverte.

O modelo de dados central permaneceu essencialmente o mesmo após a migração, e isso é um ponto importante. O Discord não precisou redesenhar o schema para mudar de Cassandra para ScyllaDB, porque o ScyllaDB é compatível com o protocolo CQL (Cassandra Query Language). A tabela de mensagens usa (channel_id, bucket) como chave de partição, onde bucket é derivado do timestamp da mensagem para evitar partições ilimitadas (um canal ativo por anos teria uma partição gigantesca sem bucketing). A chave de clusterização é o message_id, um Snowflake ID que codifica o timestamp, garantindo ordenação cronológica nativa e leituras de intervalo eficientes.

O que mudou foi a engine por baixo. O ScyllaDB é uma reimplementação do Cassandra em C++ com o framework Seastar, que usa um modelo shard-per-core: cada core da CPU tem seu próprio conjunto de dados e sua própria fila de I/O, sem compartilhamento de memória entre cores. Isso elimina a contenção de locks que é endêmica em sistemas multi-threaded com heap compartilhado. Não há GC. O gerenciamento de memória é determinístico. O resultado prático é que as latências de cauda, p99, p999, colapsam para valores muito menores e, mais importante, muito mais previsíveis.

A reescrita dos data services em Rust foi complementar e igualmente deliberada. Os serviços anteriores em Python/Go introduziam sua própria variabilidade de latência: o GC do Go, embora muito melhor que o da JVM, ainda introduz pausas; o Python tem o GIL. Rust oferece performance determinística sem runtime de GC, com segurança de memória em tempo de compilação. Para um serviço que está no caminho crítico de cada leitura e escrita de mensagem, a escolha faz sentido técnico claro. O custo é a curva de aprendizado e a velocidade de desenvolvimento menor, trade-off que o Discord avaliou como aceitável dado o perfil de carga.

A migração em si foi conduzida com dual-write e backfill. Durante a fase de transição, novas mensagens eram escritas tanto no Cassandra quanto no ScyllaDB. Um processo de migração em background lia dados históricos do Cassandra e os escrevia no ScyllaDB. Quando a paridade de dados era confirmada, o tráfego de leitura era gradualmente desviado para o ScyllaDB. Essa abordagem é conservadora e correta para dados de missão crítica, você nunca faz big-bang migration em armazenamento de mensagens de produção. O risco de perda de dados ou inconsistência é alto demais. O custo do dual-write (dobrar a carga de escrita temporariamente) é um preço razoável pela segurança operacional.

A reescrita dos data services em Rust merece análise separada porque ela revela uma filosofia de engenharia importante: quando você tem um requisito de latência de cauda agressivo, cada camada do stack precisa ser avaliada como potencial fonte de jitter. O Discord não trocou apenas o banco de dados, eles auditaram o caminho crítico de ponta a ponta e identificaram que a camada de serviço também era uma fonte de variabilidade.

O argumento técnico para Rust nesse contexto é sólido. O modelo de ownership do Rust garante que não há coleta de lixo em runtime, alocações e desalocações são determinísticas e previsíveis. Para um serviço que processa milhões de operações de leitura e escrita por segundo, a ausência de pausas de GC, mesmo as sub-milissegundo do Go, se traduz em percentis de latência mais baixos e mais estáveis. Além disso, Rust tem performance próxima a C/C++ sem os riscos de segurança de memória que tornariam C++ impraticável para uma equipe de produto.

O custo real do Rust é a velocidade de desenvolvimento e o tamanho do pool de engenheiros. Rust tem uma curva de aprendizado significativa, o borrow checker é um obstáculo real para desenvolvedores vindos de linguagens com GC. Para uma empresa do tamanho do Discord, isso significa que a base de engenheiros que pode contribuir para esses serviços é menor, e o tempo de onboarding de novos engenheiros é maior. Esse é um trade-off que faz sentido para serviços de infraestrutura de baixo nível com requisitos de performance extremos, mas seria questionável para serviços de negócio de alto nível onde a velocidade de iteração é mais importante que a latência de cauda.

O que o Discord fez corretamente foi limitar o uso de Rust ao caminho crítico, os data services que ficam diretamente na frente do banco de dados. Eles não reescreveram tudo em Rust. Essa contenção é madura: você aplica a ferramenta mais cara (em termos de custo de desenvolvimento) onde o retorno é mais alto.