A incrível tecnologia por trás do armazenamento de trilhões de mensagens no Discord
Olá pessoal! Eu sou o Antonio e trabalho como Desenvolvedor de Software.
Para explicar sobre um assunto assim, exige um certo nível técnico, porém tentarei deixar o mais simples possível para que todos possam entender.
As imagens são apenas ilutrações graficas e não representam a dimensão de cada problema, utilize elas apenas com base para você imaginar.
Hoje vamos falar sobre como o Discord lida com trilhões de mensagens.
Para chegar ao Discord que conhecemos atualmente, a arquitetura do sistema evoluiu de forma drástica. Vamos falar sobre algumas das tentativas de banco de dados.
Utilizaram um banco de dados MongoDB, assim como eu e você fazemos em projetos pequenos. Porém, esse pequeno projeto, nomeado Discord, já possuía mais de 10 milhões de usuários ativos. Com isso, o custo operacional estava ficando alto e a performance estava baixa. Diante disso, o time de engenharia decide evoluir a arquitetura e utilizar modelos de bancos não relacionais semelhantes ou iguais aos de grandes empresas como Microsoft, Google, Twitter, Spotify, entre outras.
Cassandra DB
No ano de 2017, após um período de desenvolvimento, começam os efeitos dessa migração de mongo para o novo banco de dados com alta performance e uma redução de custo. Já que estamos falando de bilhões e bilhões de mensagens, até o início de 2022, eles possuíam cerca de 177 nodes de Cassandra com trilhões de mensagens.
Isso começou a se tornar um problema, porque mesmo com as melhores práticas e engenheiros do momento, o Discord começou a enfrentar problemas de instabilidade. Mensagens eram lidas mais rapidamente que escritas. Tecnicamente, é exatamente isso que acontece, porém estamos dizendo isso sobre trilhões de mensagens. Imagine que o sistema demoraria cerca de 45% a 50% a mais de tempo para enviar uma mensagem. Ou seja, uma mensagem que demoraria 1 segundo, demoraria cerca de 1,5 segundos para cada usuário.
Escolhendo um novo banco de dados.
Então, começam as pesquisas para procurar um novo banco de dados que possuísse esses requisitos:
- Escalabilidade linear
- Automatic failover
- Baixa manutenção
- Comprovado que funciona
- Desempenho previsível
- Not a blob store
- Open Source
E o ScyllaDB atendia a todos os requisitos, porém eles decidem migrar novamente para o ScyllaDB, um banco não relacional, e realizam essa migração durante meses. A nova performance foi surpreendente. Um exemplo é que o Cassandra demorava cerca de 40 a 125 ms para procurar uma mensagem e cerca de 5 a 70 ms para escrever uma nova mensagem. Porém, com o ScyllaDB, os resultados são mágicos: 15ms para procurar uma mensagem e cerca de 5ms fixo para escrever uma nova mensagem. Imagine a melhora de performance que é cerca de 5 a 6 vezes a antiga para os usuários finais, que nesse momento já eram acima de 150 milhões.
Final
Em conclusão, um produto nunca para de evoluir e cada vez que escalamos, será necessário melhorar a arquitetura, pois nem sempre o hardware é a solução.
Obrigado por ter ficado até aqui!
Até mais!