Twitter: timelines em escala (fan-out em Redis)

01 · CONTEXTO

Uma timeline é lida muito mais do que escrita

A timeline inicial do Twitter mostra a cada pessoa os tweets recentes de quem ela segue. Uma descrição pública da arquitetura da empresa, publicada pelo High Scalability, registra a assimetria que molda o projeto: cerca de 300 mil requisições por segundo eram gastas lendo timelines e apenas cerca de 6 mil por segundo eram escritas.

Quando a leitura domina desse jeito, vale mover trabalho da leitura para a escrita: gastar mais ao publicar um tweet para que abrir a timeline seja barato. Este caso acompanha essa troca, mostra onde ela quebra (contas com muitos seguidores) e como o desenho real passou a combinar os dois lados. Aqui o foco é o que o Twitter fez com Redis, e não o problema genérico de feed.

02 · PONTO DE PARTIDA

Montar a timeline na hora da leitura

A abordagem mais direta é não guardar nada pronto. Quando alguém abre a timeline, o serviço consulta o grafo de seguidores, busca os tweets recentes de cada conta seguida e ordena tudo. Não há trabalho extra ao publicar, mas cada leitura vira muitas consultas.

1. O usuário abre a timeline. O balanceador escolhe uma instância do serviço, que não tem nada pré-computado e precisa montar o resultado agora.

2. O serviço pergunta ao grafo de seguidores quais contas esse usuário segue. Quanto mais contas, mais consultas virão em seguida.

3. Para cada conta seguida, o serviço busca os tweets recentes no banco de tweets. Uma leitura da timeline se desdobra em muitas leituras, e o banco absorve esse peso a cada abertura do aplicativo.

4. O serviço junta os resultados, ordena por tempo e responde. O tempo de resposta cresce com o número de contas seguidas, e esse custo se repete em toda leitura.

03 · FAN-OUT NA ESCRITA

Entregar o tweet nas timelines no momento da escrita

A descrição da arquitetura conta que os tweets que chegam são colocados em um grande cluster Redis, e que a solução adotada foi uma abordagem de fan-out na escrita. Em vez de calcular a timeline quando alguém a lê, o sistema insere cada novo tweet nas timelines dos seguidores no momento em que ele é publicado.

1. Quem publica envia o tweet. O balanceador encaminha a requisição ao serviço de tweets, que valida e grava.

2. O tweet é gravado primeiro no banco de tweets, que guarda o conteúdo completo e não depende de nenhuma timeline.

3. Em vez de entregar a todos os seguidores dentro da requisição de quem publicou, o serviço enfileira o trabalho de entrega. A pessoa que publica não espera a fila terminar.

4. O processo de entrega consulta o grafo de seguidores e insere o identificador do tweet na timeline de cada seguidor, guardada no cache em memória. O custo cresce junto com o número de seguidores de quem publicou.

5. Quando um seguidor abre a timeline, o serviço de leitura busca a lista já pronta no cache e completa os tweets pelo identificador. A leitura deixa de percorrer o grafo de seguidores.

A mesma fonte descreve que a timeline principal de uma pessoa fica em um cluster Redis e tem no máximo 800 entradas. O limite mantém a lista pequena e cabendo em memória: o cache guarda só o trecho recente, e o que é mais antigo vem do armazenamento principal.

04 · CONTAS GRANDES

Onde o fan-out na escrita quebra e o desenho híbrido

O custo do fan-out na escrita é proporcional ao número de seguidores. Para uma conta enorme, um único tweet vira uma enxurrada de inserções, e as filas de entrega ficam atrás da demanda: a fonte afirma que as filas de fan-out de contas de alto valor se acumulam o tempo todo. A mesma fonte diz que o Twitter estava mudando de fazer todo o trabalho na escrita para fazer mais trabalho na leitura para essas contas, e dá o exemplo de não fazer fan-out de uma conta muito seguida e mesclar os tweets dela no momento da leitura.

1. Com fan-out puro, o tweet de uma conta enorme gera uma tarefa gigante. A fila de entrega enche e os tweets dessa conta demoram a aparecer, enquanto atrasam também os tweets de contas pequenas que esperam atrás.

2. No desenho híbrido, o processo de entrega continua espalhando os tweets de contas comuns, mas não espalha os de contas muito seguidas. O trabalho por tweet fica limitado.

3. Os tweets dessas contas ficam em um cache próprio, lido por muitos usuários. Como são poucos e muito lidos, esse cache tem alta taxa de acerto.

4. Ao abrir a timeline, o serviço de leitura pega a lista pronta do cache de timelines e mescla os tweets das contas grandes que a pessoa segue, buscados no cache próprio, ordenando o resultado.

5. O preço é um pouco mais de trabalho na leitura, que antes era só uma busca. Em troca, a escrita de contas grandes deixa de ser um gargalo para o resto do sistema.

Uma fonte de entrevistas de sistemas descreve o mesmo princípio de forma geral: a abordagem híbrida permite escolher entre fan-out na leitura e fan-out na escrita para cada conta. A decisão deixa de ser do sistema todo e passa a ser de cada conta.

05 · LIÇÕES

O que levar para a entrevista

Três ideias saem do caso. Primeiro, a razão entre leitura e escrita decide onde pagar o custo: se a leitura domina, pré-computar compensa. Segundo, o custo da escrita cresce com o número de seguidores, então a média esconde a cauda de contas gigantes. Terceiro, a solução raramente é um modelo puro: o desenho real mistura os dois e escolhe por conta.