Case: Twitter feed / timeline

Projetar um feed social é escolher quando o trabalho acontece: na hora em que alguém publica, ou na hora em que alguém abre o aplicativo. Tudo o mais — banco, cache, fila — decorre dessa escolha.

A assimetria é o que torna a pergunta interessante. Num feed social típico, leituras superam escritas em duas ordens de grandeza: as pessoas abrem o aplicativo dezenas de vezes por dia e publicam uma. Isso empurra o trabalho para o lado da escrita — mas só até certo ponto, e o ponto tem nome.

É o caso que faz a estratégia pura desmoronar, e tem um nome próprio em toda literatura de projeto de sistemas. Espalhar na escrita significa que publicar custa uma escrita por seguidor. Para a esmagadora maioria das contas, isso é irrelevante: algumas centenas de escritas assíncronas. Para uma conta com dezenas de milhões, é um pico de tráfego que derruba o serviço.

E o custo não é só o pico. É a latência da entrega: se espalhar para 50 milhões de caixas leva minutos, os últimos seguidores da fila veem o post muito depois dos primeiros — e num evento ao vivo isso é visível para o usuário.

Detalhe que separa quem já implementou de quem só leu sobre: a caixa de entrada guarda identificadores, não conteúdo. Copiar o texto do post para 50 mil caixas multiplica o armazenamento por 50 mil e torna a edição impossível — corrigir um erro de digitação exigiria reescrever todas as cópias.

# Caixa de entrada: só ponteiros, ordenada por tempo
feed:{user_id}  →  [ (post_id, timestamp), ... ]   # lista/sorted set em cache
                    ~800 entradas, corta o que passa disso

# Montagem
1. lê os N ids da caixa                        (1 leitura)
2. busca os posts em lote pelos ids            (1 leitura em lote)
3. busca os posts das contas grandes seguidas  (paralelo, poucas)
4. mescla por timestamp, aplica ordenação, corta em 50

# Por que cortar a caixa em ~800:
ninguém rola 800 posts. Guardar histórico infinito por usuário
multiplica armazenamento sem ninguém ler.

Feed é um dos poucos sistemas em que a consistência fraca é aceitável pelo produto, não apenas tolerada pela engenharia. Ninguém percebe que um post apareceu três segundos depois. E essa permissão é o que libera quase todas as otimizações: espalhar em segundo plano, servir de cache, ler de réplica.