Anderson LimaSoftware Engineer
21 de marzo de 2026
16 min de lectura
434 visualizaciones
Seguindo a série de system desygn vamos arquitetar o instagram passo a passo
Software Engineer
Pós-graduado em arquitetura de software e soluções. Conecto profundidade técnica com resultados de negócio para entregar produtos que as pessoas realmente usam. Também mentoro desenvolvedores e criadores em programas ao vivo, podcasts e iniciativas de comunidade focadas em tecnologia inclusiva.
Continúa explorando temas similares
Um guia completo de system design para cache distribuído com Redis e Memcached, cobrindo cache-aside, read-through, write-through, invalidação, TTL, eviction, sharding, replicação, hot keys, preven...
Um guia completo de system design para construir uma plataforma estilo Dropbox ou Google Drive com upload resumível, chunking, deduplicação, metadados, cursores de sincronização, compartilhamento,...
Um guia completo de system design para construir uma plataforma de compartilhamento de corridas lidando com milhões de viagens simultâneas, matching geoespacial em tempo real, precificação dinâmica e predição de ETA em escala global.
Una lista de 47 puntos para encontrar errores, riesgos de seguridad y problemas de rendimiento antes del lanzamiento.
Templates probados en producción, usados por desarrolladores. Ahorra semanas de setup en tu próximo proyecto.
Às 20:20, um criador publica um reel de 90 segundos. Em menos de 30 segundos, o sistema precisa:
À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.
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
| Requisito | Meta | Motivo |
|---|---|---|
| Disponibilidade | 99,99% leitura de feed | app de uso diário |
| Latência feed | < 200ms p99 sem payload de mídia | scroll exige resposta rápida |
| Ack de postagem | < 500ms p99 | usuário precisa confiança imediata |
| Início de vídeo | < 1,5s p95 | retenção de reels |
| Notificação | < 5s p95 | loop social |
| Consistência | mista | forte em ownership e eventual em contadores |
| Durabilidade | zero perda de post confirmado | confiança do criador |
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
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
Suposições:
Post metadata/dia ~= 180GB
Story metadata/dia ~= 480GB
Eventos (12B/dia) ~= 2,4TB/dia
Mídia domina custo:
Mesmo com compressão forte, escala anual entra em petabytes.
O sistema é ao mesmo tempo:
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=...
{
"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"
}
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)
);
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);
Feed é o problema central de sistemas sociais.
Combinar conteúdo de:
| Estratégia | Pro | Contra |
|---|---|---|
| fanout-on-write | leitura super rápida | custo alto para contas gigantes |
| fanout-on-read | escrita barata | leitura cara e latência maior |
media_id pronto.Stories expiram em 24h, mas geram carga alta de escrita/leitura.
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);
Reels têm dinâmica diferente do feed social:
Para reduzir latência perceptível, gerar lote curto de próximos reels (ex: 5-20) e atualizar conforme interação.
Grafo social pode usar:
Follow precisa consistência forte aparente ao usuário:
POST /v1/users/{id}/follow
Idempotency-Key: 9f3c...
Retries devem ser seguros e sem duplicar arestas.
Padrão comum:
{
"event_type": "POST_LIKED",
"post_id": "p_9901",
"user_id": "u_88",
"created_at": "2026-02-22T20:06:20Z"
}
Busca e Explore dependem de indexação e ranking específicos.
DMs são um sub-sistema próprio.
Mensagens para dispositivo offline vão para fila durável, com push para wake-up.
Insights dependem de pipeline analítico separado do caminho crítico.
Nunca usar pipeline de analytics para resposta crítica de feed/post.
feed:user:{user_id}:cursor:{cursor_key}
post:summary:{post_id}
story:tray:{user_id}
reels:session:{session_id}
search:{query_hash}:{filter_hash}
| Domínio | Chave de Shard |
|---|---|
| posts | hash(post_id) |
| feed cache | hash(user_id) |
| social graph | hash(user_id) |
| DM conversations | hash(conversation_id) |
| interactions | hash(post_id) + time bucket |
Falha parcial deve degradar qualidade, não quebrar o app inteiro.
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
);
Se ranking service cair:
Mitigações:
| Domínio | SLI | SLO |
|---|---|---|
| Feed API | p99 latência | < 200ms |
| Post create | sucesso + durabilidade | > 99,95%, perda 0 |
| Reels startup | p95 start | < 1,5s |
| Search API | p99 latência | < 250ms |
| Notifications | p95 atraso | < 5s |
x-request-id
x-user-id
x-post-id
x-session-id
x-experiment-variant
| Decisão | Opção A | Opção B | Recomendação |
|---|---|---|---|
| timeline | fanout-write | fanout-read | híbrido |
| indexação | realtime total | micro-batch | híbrido por criticidade |
| counters | sync update | async aggregate | async + reconciliação |
| global writes | global único | ownership regional | regional |
Problema: escrita explode em custo/latência.
Correção: híbrido com leitura sob demanda para celebridades.
Problema: timeout e baixa resiliência.
Correção: upload direto para object storage + processamento async.
Problema: lock contention em alta escala.
Correção: eventos + agregação assínc.
Problema: feed vazio em incidente de ML.
Correção: caminho degradado determinístico.
Problema: custo de moderação explode e qualidade cai.
Correção: controles preventivos em tempo real.
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:
Com esse framework, você consegue responder entrevistas avançadas e discutir implementação real com trade-offs claros.
| Componente | Responsabilidade |
|---|---|
| Feed Service | montar timeline personalizada |
| Post/Media Service | publicar e processar conteúdo |
| Graph Service | follow/block/restrições |
| Search/Explore | descoberta e ranking |
| Interaction Service | likes, comentários, shares |
| Story/Reel Service | consumo efêmero e vídeo curto |
| Notification Service | loop social em tempo real |
| Insights Service | analytics para criadores |
create post -> publish event -> update indexes/caches -> eligible for feed/reels -> notify
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