Design de Feed de Redes Sociais

O problema

Feed parece simples para quem olha só a interface.

O usuário abre o app e vê uma lista de posts. Só isso.

Mas, por trás dessa lista, o sistema precisa lidar com:

• leitura massiva
• escrita que pode disparar trabalho para milhões de pessoas
• atualização constante
• contas normais e contas gigantes no mesmo produto

É por isso que feed aparece tanto em entrevista. Ele parece familiar, mas obriga você a mostrar julgamento de arquitetura de verdade.

Modelo mental

A forma mais limpa de pensar em feed é separar o sistema em dois caminhos:

1. o caminho de publicar
2. o caminho de ler

Quando alguém publica, o sistema precisa salvar o post e decidir como esse conteúdo vai chegar ao feed dos seguidores.

Quando alguém abre o app, o sistema precisa devolver uma timeline rápida, consistente o suficiente e barata o bastante para rodar em escala.

Daí nascem os dois modelos clássicos:

• fanout on write: o sistema já empurra o post para as timelines dos seguidores quando ele é publicado
• fanout on read: o sistema monta a timeline quando o usuário pede para ler

O primeiro paga mais cedo. O segundo paga mais tarde.

Quase sempre a resposta madura é híbrida.

Quebrando o problema

Primeiro alinhe o tipo de feed

Antes do desenho, vale travar algumas perguntas:

• o feed é cronológico ou ranqueado?
• a primeira página precisa ser muito rápida?
• a maioria dos usuários segue poucas pessoas ou muitas?
• existem contas gigantes com dezenas de milhões de seguidores?

Sem isso, a conversa vira diagrama bonito sem critério.

O write path: quando alguém publica

No fluxo de publicação, o sistema normalmente:

1. persiste o post
2. registra um evento ou job
3. decide como distribuir esse post

Se a estratégia for fanout on write, o sistema vai gravar esse post nas timelines pré-computadas dos seguidores.

Isso costuma deixar a leitura muito boa, mas pode explodir custo quando o autor tem muitos seguidores.

O read path: quando alguém abre a timeline

No fluxo de leitura, o sistema precisa devolver uma lista pronta ou quase pronta.

Ele pode:

• ler uma timeline já materializada
• montar a timeline na hora
• ou combinar uma base pronta com alguns trechos montados no read path

Essa decisão define boa parte do custo da arquitetura.

O problema da celebridade

Se um usuário com poucos seguidores publica, fanout on write é tranquilo.

Se uma conta enorme publica, essa mesma estratégia pode virar tempestade de escrita, fila e cache invalidado ao mesmo tempo.

Por isso, sistemas reais costumam fazer algo como:

• usuários comuns usam fanout on write
• contas gigantes usam fanout on read ou algum tratamento especial

Esse tratamento especial existe porque a distribuição de seguidores não é uniforme.

Poucas contas concentram carga demais para uma solução ingênua continuar barata.

Esse é um ponto importante de entrevista, porque mostra que você não está assumindo distribuição uniforme.

Cache, paginação e ranking

Feed quase sempre tem cache em algum lugar, principalmente na primeira página.

Mas cache sozinho não resolve o desenho. Ele melhora o que já foi decidido.

Você ainda precisa explicar:

• o que está sendo cacheado
• por quanto tempo
• como a paginação funciona
• e quanto de frescor você realmente precisa

Se a primeira página precisa parecer instantânea, ela merece um desenho diferente das páginas mais fundas.

Se o feed tem ranking, entra outro custo: recomputar relevância. Isso deixa a explicação melhor quando você mostra que ranking muda o read path e não é só um detalhe visual.

Exemplo simples

Uma resposta boa em entrevista poderia soar assim:

“Eu separaria o feed em dois fluxos: publicar e ler. Quando um usuário publica, o post é salvo e um evento é emitido. Para usuários comuns, eu faria fanout on write e colocaria o post em timelines pré-computadas dos seguidores. Para contas muito grandes, eu evitaria espalhar para todo mundo na escrita e montaria parte da timeline no read path. Na leitura, eu tentaria servir a primeira página de uma timeline pronta ou em cache. Assim eu preservo boa experiência para a maioria dos casos sem transformar conta gigante em hotspot permanente.”

Essa resposta funciona porque ela:

• separa os fluxos
• mostra o trade-off central
• trata exceção importante
• evita prometer consistência perfeita sem custo

Erros comuns

• Responder “eu usaria Redis” como se isso fosse o desenho.
• Não separar publicação de leitura.
• Tratar usuário comum e celebridade do mesmo jeito.
• Ignorar paginação e primeira página quente.
• Falar de ranking sem reconhecer o custo extra.

Como um senior pensa

Quem já viu esse tipo de sistema em produção costuma reduzir a conversa a duas perguntas:

Onde eu quero pagar: na escrita ou na leitura?

Quem foge do comportamento normal e precisa de tratamento especial?

Isso limpa muita confusão.

Em vez de tentar parecer sofisticado, a pessoa mostra que sabe localizar o custo e proteger o sistema dos casos extremos.

Esse é o tipo de cenário em que resposta madura costuma dizer cedo o que aceita atrasar, o que precisa ficar rápido e para quem o desenho muda.

O que o entrevistador quer ver

Nesse cenário, o entrevistador quer ver se você:

• separa write path e read path
• entende fanout como custo real, não como buzzword
• reconhece hotspot de contas gigantes
• usa cache como apoio, não como desculpa
• explica um desenho coerente sem tentar cobrir tudo ao mesmo tempo

Feed bom não nasce de um diagrama complexo. Nasce de decidir com clareza onde o sistema vai pagar pela rapidez da timeline.

Quando você separa usuário comum de caso extremo, o desenho para de parecer teórico e começa a parecer real.