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!