DDIA acerca do modo como o Twitter alcançou escalabilidade

Este é um resumo das pág. 33-35 do livro Designing Data Intensive Applications (DDIA), sobre escalabilidade.

A primeira versão do Twitter

Na abordagem inicial do Twitter, cada novo post era diretamente inserido em grandes tabelas que armazenavam informações tais como autor, conteúdo, data-hora, post sendo respondido, etc. Quando algum usuário abria sua timeline, eram buscados de lá os últimos posts que atendiam a certos critérios (se o autor era seguido, etc). Grosseiramente falando, era um select em uns tabelões.

O problema é que esse modelo se tornou insustentável: as tabelas já cresciam apressadamente (12 mil posts por segundo), e ainda por cima pessoas solicitavam timelines 300 mil vezes por segundo. Executar essas consultas em tabelas tão grandes, 300 mil vezes por segundo, não estava performando bem.

A segunda versão do Twitter

Para lidar com isso, o Twitter mudou para uma segunda abordagem, onde cada usuário passou a ter sua própria timeline armazenada separadamente. Quando alguém fazia uma postagem, a mesma era inserida na timeline de cada um de seus seguidores.

Essa mudança tornou o ato de postar mais caro. Antes, era só um insert. Depois, passou a ser necessário buscar quais eram os seguidores e fazer múltiplos inserts. No entanto, o ato de abrir a timeline ficou mais eficiente. Antes, era necessário fazer selects caros em tabelas gigantes e, depois, tudo passou a estar pré-computado. Ou seja, a carga foi movida da leitura para a escrita. Como pessoas leem 200x mais do que escrevem, isso valia a pena.

Isso funcionou por um bom tempo, mas surgiu uma nova pedra no sapato: usuários muito famosos. Alguns usuários chegavam a ter 30 milhões de seguidores. Imagine fazer 30 milhões de inserts só para criar um novo tweet. Inviável.

A terceira versão do Twitter

Diante disso, o Twitter adotou uma medida híbrida: posts de usuários famosos voltaram a ser inseridos em tabelões. Ao abrir sua timeline, o Twitter busca tanto o conteúdo pré-computado na sua timeline quanto executa selects nos tabelões de postagens de usuários famosos, pra ver se tem algo lá para você também.

Essa medida híbrida passou a consistentemente entregar boa performance. O livro volta a falar disso no capítulo 12, mas eu não cheguei lá ainda. Se Quando eu chegar, posto aqui :D

Lembrando que o livro foi publicado em 2017, então muita coisa pode ter mudado de lá para cá.

Conclusões

Esse trecho que resumi se enquadra numa parte do livro sobre escalabilidade. Mais precisamente, quando ele fala sobre descrição de carga. Quando discutimos quanto de carga um sistema suporta, precisamos especificar de qual carga estamos falando, e carga não é tudo uma coisa só. Podemos medir o número de requests por segundo para um servidor, o número de leituras e escritas num banco de dados, o múmero de usuários simultaneamente ativos em um chat, o número de acessos a um cache, etc. O autor chama essas coisas de parâmetros de carga. Segregando adequadamente os parâmetros de carga, o Twitter foi capaz de identificar para onde valia a pena mover o custo computacional.

Meu objetivo é fazer posts conforme eu for lendo. Além do ensinamento do livro poder ser útil pra alguém, talvez isso me ajude a não dropar a leitura, como eu fiz muitas vezes, além de possivelmente me ajudar a fixar o conteúdo conforme re-explico.

Até o próximo resumão!

Muito interessante saber o que acontece por de baixo dos panos em empresas reais, muito valioso, principalmente pra esses com alta carga de dados. Já fiquei curioso em saber como o Discord lida com tanta mensagem, daí encontrei esse artigo e descobri a existência do ScyllaDB.

Fiquei hiper curioso de ler esse livro, sabe se tem uma versão traduzida pra comprar (Nem que seja em PDF/EPUB)? Tentei procurar aqui e não encontrei :/

Infelizmente, não. O mais próximo que temos é espanhol :/

Em 2011 o Twitter migrou o front-end de Ruby on Rails para uma solução própria, batizada de Blender.

Só com essa mudança, o tempo de requisição de 800ms passou para 250ms, e ainda conseguiram fazer os servidores terem 10 vezes mais capacidade.

https://www.akitaonrails.com/2011/04/16/twitter-muda-de-ruby-para-java-ruby-e-3x-mais-lento-que-java

Cara, super interessante esse assunto. Para falar a verdade, não conhecia o livro que foi mencionado, fiquei com vontade de ler hahahaha.

Além disso, essa visão nos mostra o quão é importante só se preocupar com determinados assuntos quando for necessário. As vezes quando estamos desenvolvendo um Side Project, queremos dar um passo maior que a perna, pensando em uma baita escalabilidade sem ter 1 único usuário ativo.

Obrigado pelo resumo.

A escalabilidade é um assunto bastante complexo que passa por varios desafios. Neste post voce pode encotrar mais alguns dados relacionados a escalabilidade de uma palicação web

Que eu li, seguramente este livro é um dos mais importantes da minha carreira técnica até o momento.

Esse livro é uma referência incrível com lições e estudos de caso das principais empresas de tecnologia do mundo!

Leitura super recomendada!