Cenários de API em Escala

O problema

Muita resposta de system design para API em escala vira lista de tecnologia famosa.

Redis, Kafka, load balancer, microsserviço, sharding.

Tudo entra na mesa antes de alguém responder:

• qual rota realmente importa
• qual dependência limita o fluxo
• o que o negócio aceita perder quando a carga aperta

O resultado é uma resposta com cara de arquitetura, mas sem diagnóstico.

Modelo mental

API em escala não começa pela quantidade de componentes.

Começa por quatro perguntas:

1. qual operação é mais importante
2. qual operação mais sofre quando a carga sobe
3. qual recurso satura primeiro
4. como o sistema degrada quando não consegue atender tudo

Se você responde essas quatro, boa parte da arquitetura aparece quase sozinha.

Quebrando o problema

Escolha o fluxo crítico

Nem tudo tem o mesmo peso.

Em uma API real, quase sempre existe um caminho que merece proteção prioritária.

Exemplos:

• checkout
• login
• redirect
• geração de relatório

Se você não escolhe esse fluxo cedo, acaba desenhando tudo com a mesma prioridade.

Faça uma estimativa rápida de leitura e escrita

Não precisa ser uma tese.

Mas precisa responder se o problema é dominado por:

• leitura
• escrita
• processamento pesado
• dependência externa

Também ajuda dizer se a dor principal é throughput, latência de cauda ou explosão de custo.

Média bonita esconde API que sofre no p95.

Sem isso, fica fácil propor solução elegante para gargalo que nem era o principal.

Nomeie o primeiro recurso que satura

Essa parte é onde a resposta começa a ficar séria.

Porque o gargalo normalmente não é “escala” em abstrato.

É algo concreto, como:

• CPU segurando request
• banco abrindo conexões demais
• storage lento
• serviço externo com latência ruim
• fanout ou agregação pesada

Faça a menor mudança que resolve o problema certo

Nem toda API sob carga pede microserviço, fila e cinco camadas de cache.

Às vezes a mudança certa é bem menor:

• tirar processamento pesado do request
• responder 202 Accepted
• colocar retry e rate limit
• adicionar cache só no caminho quente

Quanto mais proporcional a mudança, melhor a resposta costuma soar.

Diga como o sistema degrada

Esse passo costuma ser ignorado e é um erro.

Sistema em escala não é só o que funciona quando tudo vai bem.

É o que se comporta de forma previsível quando não aguenta mais.

Isso inclui dizer o que acontece primeiro:

• você rejeita cedo
• devolve resposta parcial
• empurra para assíncrono
• ou protege um fluxo crítico e deixa outro piorar

Se você não decide isso, o sistema decide por você do pior jeito.

Exemplo simples

Imagine uma API de geração de relatório financeiro no fim do mês.

O fluxo principal é:

1. usuário pede relatório
2. API consulta muitas tabelas
3. gera um arquivo pesado
4. devolve o resultado

Se muita gente pedir ao mesmo tempo, um gargalo provável é o processamento pesado dentro do request.

Uma resposta madura poderia ser:

O fluxo crítico é pedir relatório e receber status rápido. Eu não preciso entregar o arquivo no mesmo request. Então tiro a geração do caminho síncrono, respondo 202 Accepted, coloco o job em fila e deixo o cliente consultar status ou receber aviso quando o arquivo estiver pronto.

E ainda complementaria:

Também preciso limitar quantos jobs pesados cada conta pode disparar ao mesmo tempo, para não deixar um cliente degradar todos os outros.

Agora a resposta tem:

• fluxo principal
• gargalo nomeado
• mudança proporcional
• degradação controlada

Erros comuns

• Começar pela ferramenta, não pelo fluxo.
• Falar de escala sem falar de recurso físico ou operacional.
• Ignorar degradação aceitável.
• Supor que toda API em escala precisa da mesma arquitetura.
• Esquecer o custo operacional do componente que acabou de adicionar.

Como um senior pensa

Quem tem mais experiência costuma puxar o cenário para impacto real.

O raciocínio fica assim:

O que precisa continuar funcionando quando a demanda subir? O que pode ir para assíncrono? O que precisa ficar abaixo de uma latência específica? E o que eu recuso primeiro quando a capacidade acabar?

Essa é a diferença entre diagrama bonito e sistema defensável.

O que o entrevistador quer ver

Em entrevista, esse cenário serve para medir se você:

• escolhe um fluxo importante
• localiza o gargalo principal
• muda a arquitetura por necessidade, não por moda
• define como o sistema degrada

API em escala não é sobre quantas caixas você conhece. É sobre saber qual fluxo merece proteção e qual sacrifício o sistema aceita fazer.

Quando a degradação está clara, sua arquitetura parece real em vez de só famosa.