Como projetar um feed de rede social para 300 milhões de usuários
Como pensar, simular, otimizar e responder em entrevistas técnicas de alto nível sobre system design de timelines como o Twitter/X.
Por que isso é importante
Resposta direta: em “Como projetar um feed de rede social capaz de escalar para”, meça no seu contexto — hype e ranking não substituem eval e aceite.
Por que isso é importante
Como projetar um feed de rede social para 300 milhões de usuários. Como pensar, simular, otimizar e responder em entrevistas técnicas de alto nível sobre system design de timelines como o Twitter/X.
Nem todo conteúdo nasce para viralizar: e tudo bem
Este artigo nasceu para quem quer dominar system design de verdade, não para seguir moda passageira. Aqui, a vibe é resolver juntos — do zero ao top das entrevistas — um dos problemas mais práticos do mercado tech: projetar um feed como o do Twitter/X, explicando cada decisão e mostrando o raciocínio por trás do sistema. Não é sobre IA do momento, e sim sobre fundamentos que vão te destacar tanto em processos seletivos quanto na vida real de dev.
Atenção
Esse desafio aparece em entrevistas e simulações técnicas, com cobrança sobre cada detalhe da escolha do design! Saber explicar seu raciocínio é mais importante do que acertar a solução.
O desafio: desenhe o feed perfeito (sem IA)
O cenário: sua entrevista pede para criar um sistema de feed tipo Twitter/X, com suporte a 300 milhões de usuários ativos/dia, timeline carregando em menos de 200ms, tweets de até 280 caracteres e posts só de quem você segue — tudo ordenado por tempo. Nada de IA, só timeline bruta. Você precisa explicar fanout, caching, message queues e decisão por NoSQL… E justificar cada escolha técnica.
Atenção
Volume, performance e consistência nem sempre andam juntos — toda decisão tem tradeoff! Mostre leituras, cálculos, hipóteses e questione os requisitos: isso conta pontos na entrevista.
Calcule antes de codar: simule o problema real
Não caia direto no desenho. Antes: discuta, calcule, questione números com o entrevistador — quantos tweets por dia? Qual o tamanho real de cada post? Organize seus dados: por exemplo, 300 milhões de usuários postando 2 vezes ao dia = 600 milhões de tweets/dia, 168GB só de texto. Calcule leituras e escritas — é a base para identificar gargalos futuros.
Atenção
O segredo da entrevista é pensar alto: faça cálculos, peça médias, mostre domínio em prever volume real! Só assim o seu design faz sentido e gera impacto.
Desenhando o caminho básico: client até NoSQL
O fluxo mais simples: client → load balancer → app server → NoSQL. Tanto leitura (timeline) quanto escrita (tweet). Rode assim no simulador e… pronto, gargalo! O banco NoSQL vira o elo fraco rapidamente, tudo trava em cascata — exatamente como aconteceria na vida real diante de milhões de usuários ativos. O diagnóstico é claro: evite fazer fanout apenas on read.
Entenda
Se sua timeline lê tudo direto do banco NoSQL sem cache, você afunda sob alta concorrência, gerando timeouts, conexões perdidas e baixa experiência do usuário. Escalabilidade exige desacoplar leituras do banco principal.
Por que Fanout on Read não escala?
Cada vez que um usuário abre o feed, o app server consulta direto o banco — agora imagine isso acontecendo para 300 milhões de pessoas. O resultado? Leitura massiva e repetitiva. Sem cache, nenhuma arquitetura suporta — e toda a infraestrutura começa a travar. Isso evidencia onde estará seu primeiro gargalo operacional.
Atenção
Em sistemas de alta escala, a leitura sempre supera a escrita. O custo de ir no banco primário toda hora é altíssimo!
Cache: a muralha para sua timeline sobreviver
Solução clássica: adicionar uma camada de cache entre o app server e o NoSQL. Use Cache Aside. Configure a chave (exemplo: "timeline: "), defina TTL (ex: 5min) e estratégia de eviction (LRU funciona bem). Suba o hit rate: timelines são lidas múltiplas vezes, logo é seguro esperar 90% de acerto no cache. Cada hit no cache equivale a redução de pressão sobre o banco.
Dica técnica
Justifique seu hit rate: quanto maior a repetição dos acessos, maior o impacto positivo do cache. Assuma o padrão e explique a lógica por trás do número na entrevista.
Grandes leituras, poucas escritas: otimize para o real
Lembre: escrever um tweet acontece bem menos do que ler feeds. A arquitetura deve aguentar centenas de milhões de leituras rápidas — e agrupar escritas para não sobrecarregar o banco. O cache reduz leitura no banco, mas a atualização dele precisa ser eficiente.
Cuidado
Se o cache não for atualizado após cada tweet novo, seguidores terão cache miss e puxarão do banco, perdendo performance.
Message Queue e Workers: entregando fanout de verdade
Para manter a timeline pronta, use message queues para notificar atualizações novas para stacks de seguidores. Consuma filas com workers — cada novo tweet "espalha" nos caches dos seguidores. Combinando fanout on write + cache, você entrega performance sem sobrecarregar a leitura.
Estratégia
Combine message queue com múltiplos workers para distribuir o workload e aumentar resiliência. Assim, o gargalo deixa de ser linear!
Escalando horizontalmente: réplicas onde faltar
Escale app servers, workers e até bancos (quando possível). O segredo está em identificar onde estão os bottlenecks e horizontalizar as camadas adequadas. Simule tráfego extra e veja como a parte mais lenta se desloca conforme os recursos aumentam.
Boas práticas
Nunca escale só por escalar — monitore, ajuste e, só então, some réplicas estratégicas. Métricas em tempo real valem ouro para antecipar rupturas.
Partitioning e consistência: detalhes que fazem diferença
Para banco e cache, particione por userID, garantindo balanceamento e performance. Em sistemas assim, escolha consistência eventual para leitura da timeline; atualização em realtime depende do seu tradeoff entre complexidade e escalabilidade.
Comparação
Consistência forte só é necessária para dados críticos. Feeds podem ser eventual consistent — e isso é esperado pelo usuário!
Checklist de requisitos-chave para devs de elite
Sempre repita os requisitos antes de desenhar. Garanta: suporte a 300M de usuários/dia, timeline carregando em menos de 200ms, cache com TTL e hit rate alto, fanout para atualização rápida dos seguidores, message queue e workers bem dimensionados, particionamento correto, escalabilidade horizontal monitorada.
Simule e questione: diferença de profissional para amador
O segredo está em pegar o simulador (System Design Arena ou papel/quadro branco) e prever: onde será o gargalo? O que muda se o tráfego dobra? O que acontece nos misses e timeouts? Questione, ajuste, explique — é isso que as big techs querem ver.
Não existe só uma resposta: comente, debata, evolua
System design é área de tradeoffs. Há dezenas de caminhos possíveis. O ponto é argumentar, ouvir alternativas e melhorar. Compartilhe sua arquitetura no GitHub, adapte, suba no simulador — e veja como ela se comporta. Bônus: traga feedbacks para a comunidade!
Aprenda com erros, otimize e avance
Garanta que suas decisões técnicas tenham justificativas. Erro faz parte, o importante é iterar, simular e ir ajustando para reduzir gargalos e aumentar performance. Teste novas configurações, aumente o hit rate, altere o modelo de fanout — pratique até seu raciocínio ficar automático.
Comece a treinar seu system design agora
Pronto para criar, simular e treinar? Use a System Design Arena, nem que seja com os exemplos da própria comunidade, e desafie seu raciocínio. O próximo passo é escalar do papel para o teste prático e se destacar onde importa.
Aprofunde-se: recursos e estudos para dominar o tema
1. Vídeos detalhados em https://www.youtube.com/@DevDoido para consultas rápidas 2. Gists no GitHub com soluções em Mermaid para subir e testar no simulador 3. Clubes de prática para debater architecture com pessoas experientes Ambos recursos ajudam a acelerar seu crescimento técnico e garantir diferencial em processos seletivos.
Perguntas frequentes
Em Como projetar um feed de rede social capaz de escalar para, o que «O desafio: desenhe o feed perfeito (sem IA)» resolve de verdade?
O cenário: sua entrevista pede para criar um sistema de feed tipo Twitter/X, com suporte a 300 milhões de usuários ativos/dia, timeline carregando em menos de 200ms, tweets de até 280 caracteres e posts só de quem você segue — tudo ordenado por tempo. Nada de. Em «O desafio: desenhe o feed perfeito (sem IA)», o texto trata isso como prática — não como slogan.
Como transformar «Calcule antes de codar: simule o problema real» em checklist?
Comece pelo mecanismo descrito: Não caia direto no desenho. Antes: discuta, calcule, questione números com o entrevistador — quantos tweets por dia? Qual o tamanho real de cada post? Organize seus dados: por exemplo, 300 milhões de usuários postando 2 vezes ao dia = 600 milhões de.
Qual métrica combina com «Desenhando o caminho básico: client até NoSQL»?
Use o critério do material: O fluxo mais simples: client → load balancer → app server → NoSQL. Tanto leitura (timeline) quanto escrita (tweet). Rode assim no simulador e… pronto, gargalo! O banco NoSQL vira o elo fraco rapidamente, tudo trava em cascata — exatamente como aconteceria na. Se precisar de segundo sinal, Se sua timeline lê tudo direto do banco NoSQL sem cache, você afunda sob alta concorrência, gerando timeouts, conexões perdidas e baixa experiência do usuário. Escalabilidade exige.
O que o material alerta sobre «Por que Fanout on Read não escala?»?
O artigo alerta: Cada vez que um usuário abre o feed, o app server consulta direto o banco — agora imagine isso acontecendo para 300 milhões de pessoas. O resultado? Leitura massiva e repetitiva. Sem cache, nenhuma arquitetura suporta — e toda a infraestrutura começa a travar. Ajuste ao seu contexto em `esse-video-nao-vai-dar-view` antes de virar regra.
Perguntas frequentes
Em Como projetar um feed de rede social capaz de escalar para, o que «O desafio: desenhe o feed perfeito (sem IA)» resolve de verdade?
O cenário: sua entrevista pede para criar um sistema de feed tipo Twitter/X, com suporte a 300 milhões de usuários ativos/dia, timeline carregando em menos de 200ms, tweets de até 280 caracteres e posts só de quem você segue — tudo ordenado por tempo. Nada de. Em «O desafio: desenhe o feed perfeito (sem IA)», o texto trata isso como prática — não como slogan.
Como transformar «Calcule antes de codar: simule o problema real» em checklist?
Comece pelo mecanismo descrito: Não caia direto no desenho. Antes: discuta, calcule, questione números com o entrevistador — quantos tweets por dia? Qual o tamanho real de cada post? Organize seus dados: por exemplo, 300 milhões de usuários postando 2 vezes ao dia = 600 milhões de.
Qual métrica combina com «Desenhando o caminho básico: client até NoSQL»?
Use o critério do material: O fluxo mais simples: client → load balancer → app server → NoSQL. Tanto leitura (timeline) quanto escrita (tweet). Rode assim no simulador e… pronto, gargalo! O banco NoSQL vira o elo fraco rapidamente, tudo trava em cascata — exatamente como aconteceria na. Se precisar de segundo sinal, Se sua timeline lê tudo direto do banco NoSQL sem cache, você afunda sob alta concorrência, gerando timeouts, conexões perdidas e baixa experiência do usuário. Escalabilidade exige.
O que o material alerta sobre «Por que Fanout on Read não escala?»?
O artigo alerta: Cada vez que um usuário abre o feed, o app server consulta direto o banco — agora imagine isso acontecendo para 300 milhões de pessoas. O resultado? Leitura massiva e repetitiva. Sem cache, nenhuma arquitetura suporta — e toda a infraestrutura começa a travar. Ajuste ao seu contexto em `esse-video-nao-vai-dar-view` antes de virar regra.
Por que Fanout on Read não escala?
Cada vez que um usuário abre o feed, o app server consulta direto o banco — agora imagine isso acontecendo para 300 milhões de pessoas. O resultado? Leitura massiva e repetitiva. Sem cache, nenhuma arquitetura suporta — e toda a infraestrutura começa a travar. Isso evidencia onde estará seu primeiro gargalo operacional.