Capítulo 6 – System Design além do endpoint

Quando pensamos em desenhar sistemas, muitos desenvolvedores limitam a visão ao endpoint da API ou ao serviço que estão codando. Mas para chegar ao nível de Staff Engineer, é preciso enxergar o sistema como um todo: fluxos de dados, integrações, gargalos, custos e impactos no negócio.

System Design não é só desenhar caixinhas em um diagrama. É a habilidade de pensar em escala, trade-offs e resiliência.

⚠️ O erro da “caixa preta”

Um sênior comum enxerga seu serviço como uma caixa preta:

Recebe uma requisição
Processa
Devolve uma resposta

Um Staff Engineer, por outro lado, vê o ecossistema inteiro:

Quem consome sua API?
Quais falhas podem acontecer em upstream ou downstream?
Como o serviço se comporta sob picos de carga?
Qual o impacto de custo se o tráfego dobrar?

Essa mudança de perspectiva é o que separa quem coda endpoints de quem desenha sistemas.

💳 Exemplo prático: o fluxo de pagamentos via PIX

Imagine uma instituição financeira que processa pagamentos via PIX. De fora, parece simples:

Cliente → envia pagamento → banco processa → recebedor recebe.

Mas na prática, o sistema envolve:

API de iniciação de pagamento (recebe a ordem)
Serviço de validação antifraude
Mensageria para orquestrar eventos
Conector com o sistema central do BACEN
Serviço de liquidação financeira
Notificação para o recebedor
Monitoramento e auditoria para compliance

Se qualquer ponto falhar, o usuário não pode esperar para ver depois, estamos lidando com dinheiro real.

Um bom system design para esse cenário precisa considerar:

Idempotência: evitar duplicidade de pagamentos
Resiliência: se o antifraude cair, há fallback?
Escalabilidade: milhões de PIX simultâneos no horário de pico
Custo: cada transação tem um custo, como otimizar?

🏙️ Metáfora: construir uma cidade, não uma casa

Construir uma casa = fazer um endpoint isolado. Construir uma cidade = pensar em ruas, energia, esgoto, transporte, hospitais “tudo conectado”.

O Staff Engineer precisa pensar como o urbanista da cidade tecnológica.

⚙️ Pilares de um bom System Design

🧠 Exercício prático

Escolha um sistema que você conhece (ex: login, checkout, mensageria) e responda:

Quais são os principais pontos de falha?
Como o sistema escala sob picos de carga?
O que acontece se um serviço crítico cair?
Qual é o custo por transação, e como reduzi-lo?

💬 Staff Insight

“System Design não é sobre desenhar caixinhas bonitas. É sobre prever falhas, custos e impactos antes que eles aconteçam.”

🧭 Checklist prático

Consigo explicar como meu sistema se conecta ao ecossistema maior?
Já considerei trade-offs entre disponibilidade, custo e resiliência?
Minhas decisões técnicas estão documentadas e visíveis para outros times?
Sei qual seria o gargalo se o tráfego dobrasse amanhã?

👉 Com esse capítulo, você começa a pensar como arquiteto de sistemas, não apenas como desenvolvedor. No próximo, vamos mergulhar em arquitetura distribuída, explorando eventos, filas e microservices, pilares fundamentais para o pensamento de Staff Engineer.