Framework de System Design — como engenheiros sênior abordam um problema novo

Em 2012, o time de engenharia do Instagram foi adquirido pelo Facebook com 13 engenheiros operando uma plataforma com 30 milhões de usuários. O que permitiu que um time tão pequeno construísse algo com essa escala não foi talento excepcional individual — foi disciplina de design. Antes de construir qualquer componente, o time fazia perguntas que a maioria dos engenheiros só faz depois: "qual é o padrão de acesso dominante?", "o que o sistema precisa tolerar quando falha?", "onde vão estar os nossos usuários geograficamente?". Essas perguntas, feitas no momento certo, evitam meses de retrabalho.

System design é a prática de tomar decisões de arquitetura antes de escrever código — e documentar essas decisões de forma que outros possam entendê-las, questionar e evoluir. Não é um exercício exclusivo de entrevistas: é o que acontece toda vez que um time precisa construir algo que vai crescer além de um único servidor, servir mais de uma classe de usuários, ou sobreviver à saída dos engenheiros que o construíram originalmente. O framework apresentado aqui é a estrutura que separa "escrever código que funciona" de "design um sistema que escala, falha gracefully, e pode ser operado por pessoas que não o construíram".

Por que design antes de código

A tentação de começar a codificar é real e tem nome: a falácia da concretude. Código parece progresso. Um diagrama parece especulação. Mas a realidade de sistemas que crescem é que decisões de arquitetura tomadas cedo têm consequências que durarão anos. Trocar o banco de dados de um sistema em produção com 100M registros custa meses de trabalho e risco elevado. Trocar antes de escrever a primeira linha de código custa uma hora de discussão.

As decisões que são difíceis de reverter depois que o sistema está em produção:

• Modelo de dados: como os dados estão estruturados define quais queries são rápidas e quais são impossíveis. Um schema de banco escolhido para o padrão de acesso errado exige migração total, não patch.
• Modelo de consistência: decidir que o sistema é eventually consistent depois que os usuários já assumem consistência forte é uma mudança de contrato — não só de implementação.
• Fronteiras de serviço: num monolito que precisa ser dividido, as fronteiras erradas geram distributed monolith — o pior dos dois mundos. As fronteiras certas emergem de entender os domínios antes de cortar o código.
• Estratégia de particionamento: o critério pelo qual você particionará o banco (por user_id? por data? por região?) determina quais queries cruzam partições (caras) e quais ficam locais (baratas). Mudar o critério depois exige reparticionamento completo.

Passo 1 — Clarificar requisitos

O maior desperdício em projetos de software não é código mal escrito — é código corretamente escrito para o problema errado. A clarificação de requisitos é o momento de reduzir a ambiguidade antes que ela se transforme em semanas de implementação na direção incorreta.

A separação fundamental é entre requisitos funcionais — o que o sistema faz — e requisitos não-funcionais — como ele se comporta. Engenheiros com menos experiência tendem a focar nos funcionais e assumir os não-funcionais. Os não-funcionais são precisamente o que determina a arquitetura.

Requisitos funcionais — o que clarificar

Para qualquer sistema novo, as perguntas que evitam retrabalho:

• Qual é o fluxo principal do usuário? Do ponto de entrada ao resultado, passo a passo. Se não consegue articular isso em 3 frases, o requisito ainda não foi entendido.
• Quais features são MVP e quais são futuras? Design para o MVP com extensibilidade para o futuro — não design para o futuro desde o início. Cada feature a mais no MVP é complexidade que precisa ser operada.
• Há diferentes classes de usuário? Um sistema que serve tanto consumidores finais quanto parceiros de API tem padrões de uso completamente diferentes — e às vezes precisam de caminhos de código separados.
• O que acontece nos casos edge? O que o sistema faz quando o usuário cancela uma operação no meio? Quando o mesmo usuário tenta criar dois recursos com o mesmo nome? Casos edge descobertos depois da implementação custam mais que casos edge descobertos no design.

Requisitos não-funcionais — as perguntas que definem a arquitetura

Escala: quantos usuários ativos? Quantas operações por segundo no pico? O crescimento é linear, sazonal (Black Friday), ou em spike (lançamento de produto)? A diferença entre 1k e 1M requisições por segundo não é só uma questão de provisionar mais servidores — são arquiteturas fundamentalmente diferentes.

Latência: qual é o SLO de latência? Para qual operação? Latência de escrita e leitura frequentemente têm requisitos diferentes — um sistema de analytics pode tolerar escrita lenta se a leitura for rápida. Latência P99 é mais relevante que P50 porque é o que os usuários mais reclamam: o caso médio está bom, o outlier está terrível.

Disponibilidade: 99.9% significa 8.7 horas de downtime por ano aceitável. 99.99% significa 52 minutos. Essa diferença de um nove a mais implica redundância ativa, zero single points of failure, e complexidade operacional significativamente maior. Disponibilidade mais alta custa mais — tanto em infraestrutura quanto em complexidade de design. Vale a pena perguntar: qual é o custo de 1 hora de downtime para o negócio?

Consistência: o sistema pode servir dados desatualizados? Por quanto tempo? Isso varia por operação: o saldo de uma conta bancária não pode estar desatualizado; o número de curtidas em um post pode estar 5 segundos atrás sem problema. Consistência mais forte significa coordenação mais cara e latência maior. Consistência eventual abre espaço para designs mais escaláveis mas exige que a aplicação lide com a possibilidade de ver dados diferentes dependendo de qual réplica atender a requisição.

Durabilidade: perda de dados é aceitável? Em que cenário? Uma sessão de jogo perdida em crash de servidor é tolerável. Uma transação financeira perdida não é. Durabilidade alta implica write-ahead logs, replicação síncrona, e estratégias de backup que adicionam latência e complexidade.

Geolocalização e compliance: o sistema é global? Há requisitos de data residency — dados de usuários europeus não podem sair da Europa por GDPR? Isso transforma um problema de arquitetura em um problema de replicação multi-região com isolamento geográfico, o que é significativamente mais complexo.

Passo 2 — Estimar escala

Estimation é o passo que traduz requisitos em números que informam decisões de arquitetura. O objetivo não é precisão — é ordem de magnitude. A diferença entre "precisamos de cache" e "não precisamos de cache" é derivada de estimation, não de instinto.

As estimativas fundamentais, derivadas dos requisitos:

# Exemplo: sistema de URL shortener
# DAU: 10M usuários ativos por dia
# Razão leitura:escrita = 100:1 (redirects vs criações)
# Retenção: URLs ficam por 5 anos

# --- QPS ---
# Writes: 10M DAU × 1 URL/dia ÷ 86400s ≈ 116 writes/s  (pico: ~350/s)
# Reads:  116 × 100                    ≈ 11.600 reads/s (pico: ~35k/s)

# --- Storage ---
# Tamanho por registro: short_code(7) + original_url(~100) + metadata(~50) ≈ 200 bytes
# Writes/dia: 116 × 86400 ≈ 10M URLs/dia
# Storage/ano: 10M × 365 × 200 bytes ≈ 730 GB/ano
# Em 5 anos: ~3.6 TB (sem replicação)
# Com replicação 3×: ~11 TB

# --- Banda de rede (reads) ---
# Resposta de redirect: ~500 bytes (headers + body mínimo)
# 11.600 reads/s × 500 bytes ≈ 5.8 MB/s em steady state
# Pico: ~18 MB/s — bem dentro de uma única instância de CDN

O que os números acima respondem diretamente:

• 35k reads/s no pico: um único PostgreSQL não aguenta sem cache. Redis na frente é necessário desde o início.
• 350 writes/s: um PostgreSQL aguenta, mas com índice bem escolhido. Sharding não é necessário no MVP.
• 11 TB em 5 anos: storage é gerenciável, mas particionamento por data pode ser útil para arquivar URLs expiradas sem afetar as ativas.
• 18 MB/s no pico: CDN faz sentido para distribuição geográfica, mas não por razão de banda — por latência.

Estimation é desenvolvida em profundidade no Conceito 02. O ponto aqui é que o resultado de estimation é um conjunto de restrições que eliminam opções arquiteturais: "não precisamos de sharding agora", "precisamos de cache desde o dia 1", "CDN é sobre latência, não capacidade".

Passo 3 — Definir contratos de API

Definir a API antes de desenhar a arquitetura interna não é formalismo — é uma técnica de clareza. Se você não consegue definir o contrato da API, você não entendeu o que o sistema precisa fazer. A API é também o ponto de acoplamento entre serviços: uma API bem definida permite que frontend, mobile, e serviços parceiros evoluam independentemente do backend.

Para um sistema novo, o nível de detalhe adequado é o suficiente para implementar sem fazer perguntas — não uma spec OpenAPI completa, mas mais do que "POST /urls retorna a URL curta":

POST /urls
  Authorization: Bearer {token}
  Body: {
    original_url: string (required, max 2048 chars),
    custom_alias: string? (3-30 chars, [a-zA-Z0-9-_]),
    expires_at: ISO8601? (null = nunca expira)
  }
  Response 201: {
    url_id: UUID,
    short_code: string,
    short_url: string,   # "https://shr.tt/{short_code}"
    original_url: string,
    expires_at: ISO8601 | null,
    created_at: ISO8601
  }
  Response 409: { error: "alias_already_taken", alias: string }
  Response 422: { error: "invalid_url", reason: string }

GET /{short_code}
  Response 302: Location: {original_url}
               X-Cache: HIT | MISS
  Response 404: { error: "not_found" }
  Response 410: { error: "expired", expired_at: ISO8601 }

O detalhe dos status codes não é perfeccionismo: 409 vs 422 informam ao cliente a causa do erro e o que fazer a seguir. 410 Gone vs 404 Not Found é a diferença entre "nunca existiu" e "existiu mas expirou" — o cliente pode comunicar isso diferentemente ao usuário. Esses detalhes emergem de pensar no contrato antes de implementar, não depois.

Passo 4 — Arquitetura de alto nível

A arquitetura de alto nível é o mapa do sistema: quais componentes existem, como se comunicam, e onde fica o estado. O nível de abstração é deliberado — não é pseudocódigo nem diagrama de sequência completo. É o suficiente para que um engenheiro novo no sistema entenda os blocos principais antes de mergulhar em qualquer um deles.

Os componentes que aparecem em quase todo sistema distribuído:

• Load balancer / API Gateway: ponto de entrada único, distribuição de tráfego, terminação de TLS, autenticação/autorização, rate limiting. No diagrama de alto nível, é um único bloco — os detalhes internos (L4 vs L7, algoritmo de balanceamento) ficam para o deep dive se for crítico.
• Application servers (stateless): a lógica de negócio fica aqui. São stateless para que possam ser escalados horizontalmente sem coordenação — o estado fica nos stores externos (banco, cache, object storage).
• Primary database: onde está o source of truth. A escolha de SQL vs NoSQL, e qual banco específico, deve ser justificada pelos padrões de acesso e requisitos de consistência — não por preferência.
• Cache: Redis ou Memcached na frente do banco para leituras frequentes. A decisão de o que cachear, com qual TTL, e qual estratégia de invalidação é um dos deep dives mais importantes.
• Message queue: para desacoplar operações que não precisam bloquear o request do usuário. Enviar email de confirmação não precisa ser síncrono — publicar um evento para um worker processar assincronamente.
• Object storage: S3 ou equivalente para arquivos binários, imagens, vídeos. Nunca armazenar binários em banco relacional em produção.
• CDN: para conteúdo estático e para redução de latência geográfica. A decisão de usar CDN deve ser motivada por um requisito — latência global ou redução de custo de egress, não por ser "best practice".

O erro mais comum neste passo: nível de detalhe incorreto. Discutir índices de banco de dados antes de decidir qual banco usar é detalhe de implementação antes de decisão arquitetural. Propor sharding horizontal antes de verificar que o volume realmente exige é over-engineering não motivado. A arquitetura de alto nível deve ser a versão mais simples que atende aos requisitos — e os deep dives adicionam complexidade onde os números justificam.

Passo 5 — Deep dives em componentes críticos

Este é o passo onde design de sistemas se torna engenharia real: identificar onde estão os problemas difíceis e resolver com precisão. A heurística para escolher onde aprofundar: onde os requisitos não-funcionais mais exigentes se manifestam? Se o requisito é latência global P99 < 50ms, o mecanismo de cache e a estratégia de CDN merecem deep dive. Se é consistência em writes distribuídos, o mecanismo de replicação e o protocolo de consensus. Se é throughput de 1M eventos/segundo, o pipeline de ingestão e particionamento.

Um deep dive bem feito responde quatro perguntas sobre o componente:

1. Qual problema específico ele resolve, com números? Não "precisamos de cache para performance", mas "sem cache, 35k reads/s vão ao banco; com cache com hit rate de 95%, o banco recebe 1.7k reads/s — dentro da capacidade de uma única instância com réplicas de leitura".
2. Quais alternativas foram consideradas e por que foram descartadas? "Consideramos Memcached mas escolhemos Redis porque precisamos de estruturas de dados complexas para o leaderboard de analytics, e Redis Cluster nos dá HA sem configuração adicional".
3. Quais casos edge o componente precisa tratar? O que acontece quando o Redis fica indisponível? O sistema degrada gracefully (vai direto ao banco com latência maior) ou para completamente? Cache stampede (milhares de requisições vão ao banco simultaneamente após expiração de um item popular) — como mitigar? (probabilistic early expiration, mutex lock no primeiro acesso)
4. Como o componente falha e qual o impacto? Failure modes não são exceções — são parte do design. Um sistema que só funciona quando todos os componentes estão saudáveis não é um sistema de produção.

Passo 6 — Trade-offs e limitações

Todo design de sistema é uma coleção de trade-offs. Não há design correto — há design que prioriza os atributos certos para o problema específico. Nomear os trade-offs explicitamente serve dois propósitos: demonstra que as escolhas foram conscientes (não acidentais), e cria um mapa para quando os requisitos mudarem — "se o requisito de consistência mudar, esse componente precisa ser revisitado".

Os trade-offs que aparecem em quase todo sistema:

• Consistência vs disponibilidade: em um partition event, o sistema responde com dado possivelmente desatualizado (prioriza disponibilidade) ou para de responder até ter dado consistente (prioriza consistência)? A resposta correta depende do domínio. Sistemas financeiros priorizam consistência. Sistemas de social feed priorizam disponibilidade.
• Latência vs throughput: batching aumenta throughput mas aumenta latência. Processar requisições individualmente reduz latência mas reduz throughput. A escolha depende do SLO: se o requisito é latência P99, batching é o inimigo; se é throughput total, batching é amigo.
• Custo vs performance: manter dados quentes em cache Redis custa mais do que ir ao banco. CDN custa mais do que servir da origem. A pergunta é se o custo é justificado pelo requisito de latência ou pelo volume de requisições.
• Complexidade vs confiabilidade: cada componente adicionado ao sistema é mais um ponto de falha, mais uma coisa para operar, e mais conhecimento necessário no time. Adicionar Kafka para uma fila assíncrona que processa 10 mensagens/segundo é complexidade sem benefício — um cron job simples resolveria. Adicionar Kafka para 100k mensagens/segundo com múltiplos consumidores é justificado.

Design sessions com times reais

No trabalho, design não é um processo solitário — é uma sessão colaborativa com o time, product, e às vezes stakeholders de outras áreas. As dinâmicas são diferentes de um processo individual:

Design reviews: o design é proposto por uma pessoa (ou um pequeno grupo) e revisado pelo time mais amplo. A função da revisão é encontrar os problemas que o designer não viu — não validar o design. Um design review onde ninguém levanta problemas ou alternativas ou é um design perfeito (raro) ou é um time que não está engajado (comum). Engenheiros sênior facilitam revisões onde objeções são bem-vindas e tratadas com seriedade.

ADRs (Architecture Decision Records): a ferramenta padrão para documentar decisões de design que sobrevivem à sessão. Um ADR captura: o contexto do problema, a decisão tomada, as alternativas consideradas, e as consequências — positivas e negativas. ADRs ficam no repositório junto com o código, para que qualquer engenheiro que chegue meses depois entenda por que o sistema tem a forma que tem. Sem ADRs, o conhecimento de design fica nas cabeças das pessoas que participaram — e vai embora quando elas saem.

# Formato mínimo de um ADR
# docs/decisions/0042-usar-redis-para-cache-de-urls.md

## Status
Aceito (2024-03-15)

## Contexto
O serviço de redirect processa ~35k reads/s no pico.
PostgreSQL com as réplicas atuais satura em ~8k reads/s.
Precisamos de uma camada de cache na frente do banco.

## Decisão
Usaremos Redis 7 com cluster mode (3 shards, 1 réplica cada)
para cachear mapeamentos short_code → original_url com TTL de 1h.
Cache aside: a aplicação verifica Redis, em miss vai ao banco e popula.

## Alternativas consideradas
- Memcached: descartado porque precisamos de TTL por item e
  estruturas de dados para analytics futuro (Redis Sorted Sets).
- Cache em memória local (Caffeine): descartado porque múltiplas
  instâncias do serviço teriam caches inconsistentes após writes.
- Aumentar réplicas de leitura do PostgreSQL: cobre o volume, mas
  não reduz latência de queries complexas de analytics.

## Consequências
+ Leitura de redirect passa de ~5ms (banco) para ~0.5ms (Redis).
+ Banco recebe ~1.7k reads/s no steady state (95% hit rate estimado).
- Sistema agora tem dependência adicional: Redis indisponível
  degrada para leitura direta no banco (circuit breaker necessário).
- Cache stampede possível em expiração de URLs muito populares;
  mitigar com probabilistic early expiration (ver implementação).

Iteração no design: o primeiro design raramente é o final. O processo saudável é: propor um design, receber feedback, identificar os problemas que o feedback expõe, iterar. Engenheiros experientes tratam seu design como hipótese, não como solução — e ficam genuinamente curiosos quando alguém encontra um problema, não defensivos.

Sinais de maturidade em design

O que diferencia design de um engenheiro sênior não é conhecimento de tecnologias — é a qualidade das perguntas que ele faz e dos problemas que identifica.

Design pensando em falhas: todo componente vai falhar. A questão é o que acontece quando falha. Um design que só funciona quando tudo está saudável não é um design de produção. "O que acontece quando o Redis está indisponível?" não é pergunta paranoica — é a pergunta que previne o incidente às 3h da manhã.

Design pensando em operação: o sistema vai ser operado por pessoas que não o construíram, às vezes às 3h da manhã sob pressão. Logs que permitem diagnóstico rápido, métricas que expõem o estado interno, e runbooks que descrevem os cenários de falha mais comuns não são extras — são parte do design.

Design pensando em evolução: o sistema vai precisar mudar. Features serão adicionadas, padrões de uso vão divergir do previsto, requisitos de negócio vão mudar. Um design que não pode evoluir sem reescrita completa tem vida útil curta. As decisões que mais importam para evolução são as fronteiras — entre serviços, entre componentes, entre dados de diferentes domínios.

Dimensionamento honesto: propor a solução mais simples que atende aos requisitos atuais, com uma análise de quando o sistema precisaria evoluir e em que direção. Over-engineering tem custos reais: mais complexidade para operar, mais tempo para implementar, mais superfície para bugs. Under-engineering tem custos diferentes: dívida técnica que acumula juros quando o sistema cresce além do que foi projetado. A calibração entre os dois é uma das habilidades mais valiosas de um engenheiro sênior.

Decisões de engenharia

Perguntas de entrevista

Exercícios práticos