Projetando o Instagram em Escala Global: Um Guia Completo de System Design

Às 20:20, um criador publica um reel de 90 segundos. Em menos de 30 segundos, o sistema precisa:

• receber upload de vídeo,
• processar variações de bitrate,
• rodar checagens de segurança,
• atualizar candidatos de recomendação,
• disparar notificações,
• tornar o conteúdo elegível para Explore.

Às 20:05, o mesmo conteúdo recebe dezenas de milhares de interações por minuto, comentários fora de ordem e consumo simultâneo em múltiplas regiões.

Do lado do usuário, tudo deveria parecer imediato.

Do lado do sistema, isso é um conjunto de pipelines acoplados por eventos, com requisitos diferentes de latência e consistência.

Este artigo detalha os trade-offs reais que fazem uma arquitetura desse tipo funcionar em escala.

Sumário

• Análise de Requisitos
• Cálculos de Envelope
• Arquitetura de Alto Nível
• Design de API
• Modelagem de Dados
• Home Feed (Core 1)
• Upload e Processamento de Mídia (Core 2)
• Stories e Conteúdo Efêmero (Core 3)
• Reels e Descoberta (Core 4)
• Grafo Social e Follow (Core 5)
• Comentários, Likes e Engajamento (Core 6)
• Busca, Hashtags e Explore
• Notificações
• DMs
• Insights para Criadores
• Caching e Sharding
• Distribuição Global e CDN
• Confiabilidade e Tolerância a Falhas
• Segurança, Abuse e Privacidade
• Observabilidade e SLOs
• Dicas de Entrevista
• Anti-Patterns
• Conclusão
• Referências
• Referência Rápida

Análise de Requisitos

Uma resposta madura começa delimitando o problema. Instagram-like pode incluir dezenas de features. Para system design, você precisa priorizar o caminho crítico.

Diagramas utlizados disponíveis no link:

https://link.excalidraw.com/l/7XRBb57RGJp/3ynyA3ADUk0

Requisitos Funcionais

1. Publicar foto/vídeo/carrossel.
2. Consumir feed personalizado.
3. Follow/unfollow.
4. Like e comentário.
5. Compartilhar via DM.
6. Criar/visualizar stories (TTL 24h).
7. Publicar e assistir reels.
8. Receber notificações.
9. Buscar usuário, hashtag e conteúdo.
10. Mensagens 1:1 e grupos.

Requisitos Não-Funcionais

Escala Assumida

DAU: 500 milhões
Posts/dia: 150 milhões
Stories/dia: 600 milhões
Uploads de reels/dia: 80 milhões
Likes/dia: 10 bilhões
Comentários/dia: 1 bilhão
Requests de feed/dia: 200 bilhões
DMs/dia: 120 bilhões

Perguntas de Clarificação

1. Feed cronológico ou rankeado?
2. Stories entram no mesmo ranking do feed?
3. DM com E2E está em escopo?
4. Qual limite de followers para contas gigantes?
5. Qual prioridade: speed-to-market ou escalabilidade de longo prazo?

Cálculos de Envelope

QPS

Posts/s médio = 150.000.000 / 86.400 ~= 1.736
Pico (8x) ~= 13.888

Feed req/s médio = 200.000.000.000 / 86.400 ~= 2.314.815
Pico (3x) ~= 6.944.445

Likes/s médio = 10.000.000.000 / 86.400 ~= 115.740
Pico (5x) ~= 578.700

Armazenamento de Metadados

Suposições:

• metadata post: 1,2KB
• metadata story: 0,8KB
• evento de interação: 200B

Post metadata/dia ~= 180GB
Story metadata/dia ~= 480GB
Eventos (12B/dia) ~= 2,4TB/dia

Mídia

Mídia domina custo:

• imagem renderizada e derivados,
• vídeo com múltiplos bitrates,
• thumbnails,
• réplicas CDN.

Mesmo com compressão forte, escala anual entra em petabytes.

Insight

O sistema é ao mesmo tempo:

1. pesado em metadata/ranking no backend,
2. pesado em distribuição de mídia na borda,
3. pesado em eventos para analytics e ML.

Arquitetura de Alto Nível

Princípios

1. Separar claramente planos de leitura e escrita.
2. Event-driven para visões derivadas.
3. Evitar fanout sincrônico no caminho de request crítico.
4. Degradar com qualidade em falhas parciais.

Design de API

Endpoints Principais

POST /v1/posts
GET /v1/feed/home?cursor=...
POST /v1/users/{id}/follow
DELETE /v1/users/{id}/follow
POST /v1/posts/{id}/like
POST /v1/posts/{id}/comment
POST /v1/stories
GET /v1/stories/tray
POST /v1/reels
GET /v1/reels/discover
GET /v1/search?q=...

Contrato de Postagem

{
  "idempotency_key": "a6f9d2b7-564a-4f31-8d25-a4fc0f9b3c8a",
  "author_id": "u_123",
  "caption": "Novo reel sobre arquitetura",
  "media_refs": ["m_901"],
  "visibility": "PUBLIC",
  "location": {
    "lat": -23.56,
    "lng": -46.65
  }
}

Response:

{
  "post_id": "p_9901",
  "status": "ACCEPTED",
  "created_at": "2026-02-22T20:03:01Z"
}

Idempotency Table

CREATE TABLE idempotency_records (
  idempotency_key VARCHAR(64) NOT NULL,
  user_id BIGINT NOT NULL,
  request_hash CHAR(64) NOT NULL,
  response_code INT NOT NULL,
  response_body JSONB NOT NULL,
  created_at TIMESTAMP NOT NULL,
  expires_at TIMESTAMP NOT NULL,
  PRIMARY KEY (idempotency_key, user_id)
);

Modelagem de Dados

Entidades Core

1. User
2. Post
3. Story
4. Reel
5. FollowEdge
6. Like
7. Comment
8. FeedEntry
9. Notification
10. Message

Tabelas Exemplo

CREATE TABLE posts (
  post_id BIGSERIAL PRIMARY KEY,
  author_id BIGINT NOT NULL,
  post_type VARCHAR(16) NOT NULL,
  caption TEXT,
  media_json JSONB NOT NULL,
  visibility VARCHAR(16) NOT NULL,
  created_at TIMESTAMP NOT NULL,
  updated_at TIMESTAMP NOT NULL
);

CREATE INDEX idx_posts_author_created ON posts(author_id, created_at DESC);

CREATE TABLE follow_edges (
  follower_id BIGINT NOT NULL,
  followee_id BIGINT NOT NULL,
  created_at TIMESTAMP NOT NULL,
  PRIMARY KEY (follower_id, followee_id)
);

CREATE INDEX idx_follow_edges_followee ON follow_edges(followee_id, follower_id);

ER Simplificado

Home Feed (Core 1)

Feed é o problema central de sistemas sociais.

Objetivo

Combinar conteúdo de:

• contas seguidas,
• recomendações de discover,
• anúncios/regras de negócio,
• filtros de policy.

Fanout-on-Write vs Fanout-on-Read

Estratégia Híbrida

• Usuários comuns: fanout-on-write.
• Mega contas: fanout-on-read ou parcial.
• Merge final no request com cache.

Fluxo de Feed

Freshness Window

• Feed não precisa consistência forte em todos os itens.
• Janela de segundos geralmente aceitável.
• Ações do próprio usuário (postar, curtir próprio post) precisam aparecer quase instantâneo.

Upload e Processamento de Mídia (Core 2)

Fluxo de Upload

1. Cliente pede upload slot.
2. Backend retorna URL assinada.
3. Cliente envia blob direto para object storage.
4. Pipeline assínc. gera derivados.
5. Post referencia media_id pronto.

Sequência

Regras de Processamento

1. Validação de tipo por conteúdo, não extensão.
2. Malware scanning para anexos permitidos.
3. Limites por tipo/tamanho.
4. Degradação progressiva em filas cheias.

Stories e Conteúdo Efêmero (Core 3)

Stories expiram em 24h, mas geram carga alta de escrita/leitura.

Características

• TTL hard de 24h.
• consumo sequencial por tray.
• ranking baseado em afinidade/recência.

Modelagem com TTL

CREATE TABLE stories (
  story_id BIGSERIAL PRIMARY KEY,
  author_id BIGINT NOT NULL,
  media_id VARCHAR(64) NOT NULL,
  created_at TIMESTAMP NOT NULL,
  expire_at TIMESTAMP NOT NULL,
  metadata JSONB
);

CREATE INDEX idx_stories_author_expire ON stories(author_id, expire_at);

Tray Build

• Precompute parcial por usuário.
• Ajuste online por atividade recente.
• Ocultar stories vencidos sem depender de job único.

Reels e Descoberta (Core 4)

Reels têm dinâmica diferente do feed social:

• discovery-first,
• consumo em sequência,
• competição por segundos de atenção.

Pipeline de Reels

1. Candidate generators (similaridade/popularidade/fresh).
2. Ranking de watch probability + completion.
3. Constraint layer (diversidade/policy).
4. Session-level exploration.

Reels Ranking Signals

• watch-through-rate,
• skip rate,
• rewatch,
• negative feedback,
• creator trust score,
• freshness decay.

Reels Sequence

Session Queue

Para reduzir latência perceptível, gerar lote curto de próximos reels (ex: 5-20) e atualizar conforme interação.

Grafo Social e Follow (Core 5)

Operações

1. Follow/unfollow.
2. Bloqueio/restrição.
3. Sugestões baseadas em grafo.

Store de Grafo

Grafo social pode usar:

• KV wide-column otimizado,
• ou store dedicado de grafo,
• com índices auxiliares.

Follow Consistency

Follow precisa consistência forte aparente ao usuário:

• botão mudar estado imediatamente,
• feed ajusta em seguida por propagação.

Follow API Idempotente

POST /v1/users/{id}/follow
Idempotency-Key: 9f3c...

Retries devem ser seguros e sem duplicar arestas.

Comentários, Likes e Engajamento (Core 6)

Requisitos

• baixa latência de escrita,
• contadores consistentes o suficiente,
• ordenação de comentários previsível,
• moderação automática e manual.

Contadores

Padrão comum:

1. writes append-only de eventos,
2. agregação assínc para counters,
3. cache de counters quentes,
4. reconciliação periódica.

Comentários

• ordenação por recência ou relevância,
• páginas por cursor,
• anti-spam e rate limits por usuário.

Exemplo de Evento

{
  "event_type": "POST_LIKED",
  "post_id": "p_9901",
  "user_id": "u_88",
  "created_at": "2026-02-22T20:06:20Z"
}

Busca, Hashtags e Explore

Busca e Explore dependem de indexação e ranking específicos.

Busca

• full-text para usuário/caption/hashtag,
• filtros por tipo,
• autocomplete.

Explore

• candidatos por tópicos,
• ranking por afinidade + novidade + qualidade,
• diversidade para evitar repetição.

Pipeline de Indexação

Trade-off de Freshness

• Indexação realtime para atualizações críticas.
• Micro-batch para bulk updates.

Notificações

Tipos

1. likes
2. comentários
3. follows
4. menções
5. DMs
6. recomendações do sistema

Pipeline

Regras

• dedupe por tipo/alvo/janela,
• prioridades por importância,
• controle de volume para evitar spam.

DMs

DMs são um sub-sistema próprio.

Requisitos

• 1:1 e grupos,
• entrega online/offline,
• estado enviado/entregue/lido,
• anexos,
• segurança e abuse controls.

Modelo de Entrega

• at-least-once transporte,
• dedupe por client_message_id,
• ordenação best effort por conversa.

Offline Queue

Mensagens para dispositivo offline vão para fila durável, com push para wake-up.

Insights para Criadores

Insights dependem de pipeline analítico separado do caminho crítico.

Métricas

1. alcance
2. impressões
3. taxa de engajamento
4. retenção de vídeo
5. crescimento de seguidores

Arquitetura

• eventos no bus,
• agregações por janela,
• store OLAP,
• APIs de consulta com cache.

Regra

Nunca usar pipeline de analytics para resposta crítica de feed/post.

Caching e Sharding

Caches Principais

1. feed page cache por usuário
2. profile summary cache
3. counters cache
4. search query cache
5. story tray cache

Chaves

feed:user:{user_id}:cursor:{cursor_key}
post:summary:{post_id}
story:tray:{user_id}
reels:session:{session_id}
search:{query_hash}:{filter_hash}

TTLs (exemplo)

• feed entries: 5s a 30s
• story tray: 5s a 20s
• post summary: 30s a 120s com invalidação por evento
• counters: 2s a 15s

Sharding

Distribuição Global e CDN

Objetivos

1. latência baixa em leitura global,
2. isolamento regional,
3. entrega eficiente de mídia.

Topologia

Mídia

• Object storage multi-região,
• CDN com edge caching agressivo,
• URLs assinadas quando necessário.

Confiabilidade e Tolerância a Falhas

Objetivo

Falha parcial deve degradar qualidade, não quebrar o app inteiro.

Estratégias

1. Circuit breaker por dependência.
2. Timeout budgets por chamada.
3. Retry com jitter/backoff.
4. Bulkheads por domínio.
5. Fallback de ranking e listas.

Outbox Pattern

CREATE TABLE outbox_events (
  event_id UUID PRIMARY KEY,
  aggregate_type VARCHAR(32) NOT NULL,
  aggregate_id VARCHAR(64) NOT NULL,
  event_type VARCHAR(64) NOT NULL,
  payload JSONB NOT NULL,
  created_at TIMESTAMP NOT NULL,
  published_at TIMESTAMP
);

Resiliência no Feed

Se ranking service cair:

• usar ordenação simplificada por recência + afinidade cacheada,
• manter feed funcional.

Segurança, Abuse e Privacidade

Segurança

1. TLS fim-a-fim em tráfego de API.
2. tokenização e escopo por serviço.
3. least privilege para dados sensíveis.
4. criptografia em repouso.

Abuse

1. spam de comentários/DM,
2. bots de follow/unfollow,
3. fraude de engajamento,
4. conteúdo malicioso.

Mitigações:

• rate limit adaptativo,
• trust score,
• detecção de anomalia,
• moderação em camadas (automática + humana).

Privacidade

• controles de visibilidade,
• ferramentas de bloqueio/restrição,
• retenção minimizada de dados,
• trilha de auditoria.

Observabilidade e SLOs

SLOs de Exemplo

Golden Signals

Sistema

• latência,
• erro,
• saturação,
• throughput.

Produto

• CTR feed,
• watch time reels,
• staleness feed,
• delivery delay de notificação.

Correlação

x-request-id
x-user-id
x-post-id
x-session-id
x-experiment-variant

Dicas de Entrevista

Estrutura recomendada

1. Clarifique escopo rapidamente.
2. Faça cálculos de escala.
3. Desenhe arquitetura macro.
4. Deep dive no feed e mídia pipeline.
5. Cubra confiabilidade e anti-abuse.
6. Feche com trade-offs claros.

Erros comuns

1. ignorar assimetria leitura/escrita,
2. ignorar pipeline de mídia,
3. não explicar fallback,
4. esquecer observabilidade,
5. tratar todos os dados como consistência forte.

Tabela de Trade-offs

Anti-Patterns

1) Fanout sincrônico para mega contas

Problema: escrita explode em custo/latência.

Correção: híbrido com leitura sob demanda para celebridades.

2) Mídia no caminho crítico da API de postagem

Problema: timeout e baixa resiliência.

Correção: upload direto para object storage + processamento async.

3) Contador forte em toda curtida/comentário

Problema: lock contention em alta escala.

Correção: eventos + agregação assínc.

4) Sem fallback de ranking

Problema: feed vazio em incidente de ML.

Correção: caminho degradado determinístico.

5) Ignorar abuse controls desde início

Problema: custo de moderação explode e qualidade cai.

Correção: controles preventivos em tempo real.

Conclusão

Projetar um Instagram em escala é organizar sistemas com cargas muito diferentes sem perder simplicidade de experiência para o usuário.

A arquitetura que escala combina:

1. feed e ranking otimizados para leitura,
2. pipeline de mídia assínc robusto,
3. eventos como espinha dorsal,
4. degradação previsível em falhas,
5. observabilidade e anti-abuse de nível operacional.

Com esse framework, você consegue responder entrevistas avançadas e discutir implementação real com trade-offs claros.

Referências

• Meta Engineering
• Apache Kafka Documentation
• Redis Documentation
• Elasticsearch Documentation
• Google SRE Book
• Designing Data-Intensive Applications

Referência Rápida

Componentes

Regras Críticas

1. Nunca acoplar mídia pesada ao request crítico.
2. Nunca depender de caminho único de ranking.
3. Nunca ignorar staleness de feed/contadores.
4. Sempre tratar retries como comportamento normal.
5. Sempre ter plano de degradação por dependência.

Fluxo Base

create post -> publish event -> update indexes/caches -> eligible for feed/reels -> notify

Prática de Entrevista

1. Projete feed para contas com 100M followers.
2. Otimize startup de reels para redes móveis lentas.
3. Evite duplicação de likes em retry storms.
4. Mantenha discover relevante com baixa latência.
5. Mitigue spam em comentários e DMs.

Você agora tem um blueprint completo para system design de plataforma estilo Instagram, com foco em escala, confiabilidade e trade-offs de produção.

#SystemDesign #Instagram #FeedRanking #Reels #Stories #SocialGraph #SistemasDistribuídos #Escalabilidade #EntrevistaTécnica