Cenarios reais / Cenarios de API em escala
Cenarios de API em escala
Cenarios de API em Escala
Como pensar em API sob carga sem cair em resposta genérica de sistema distribuído.
O problema
Quando aparece um cenário de API em escala, muita resposta vira lista de tecnologia.
Cache, fila, particionamento, balanceador, microsserviço.
O problema é que nada disso ajuda muito se você ainda não explicou qual fluxo está sofrendo e o que está saturando primeiro.
Modelo mental
Cenário real de API precisa começar pelo caminho crítico.
Ou seja: qual rota, qual carga, qual dependência e qual degradação ainda é aceitável.
A pergunta útil aqui costuma ser:
O que esse fluxo precisa continuar fazendo bem mesmo quando o tráfego cresce?
Quebrando o problema
Uma forma simples de estruturar esse cenário é esta:
- escolha o fluxo mais importante
- diga qual parte dele satura primeiro
- proponha a mudança mais direta para aliviar esse ponto
- explique como o sistema degrada quando ainda não dá para atender tudo
Isso evita resposta grande demais e útil de menos.
Exemplo simples
Imagine uma API de geração de relatório que sobe muito no fim do mês.
Uma resposta fraca seria:
Eu colocaria cache, fila e microserviços.
Uma resposta melhor seria:
O gargalo principal está na geração pesada síncrona. Eu tiraria esse trabalho da requisição, colocaria processamento assíncrono e devolveria status de execução para o cliente acompanhar.
Agora existe leitura do cenário, não só repertório.
Erros comuns
- responder com tecnologia antes de descrever o fluxo
- falar de escala sem explicar gargalo
- não definir degradação aceitável
- tratar todo caso de alto tráfego como se pedisse a mesma arquitetura
Como um senior pensa
Um senior forte puxa o cenário para impacto real.
Normalmente isso soa assim:
Antes de desenhar solução, eu quero entender qual parte desse fluxo precisa continuar rápida, qual parte pode sair do síncrono e onde a saturação aparece primeiro.
O que o entrevistador quer ver
Em entrevista, isso costuma mostrar maturidade rápido:
- você pensa em fluxo e recurso, não só em bloco arquitetural
- você sabe aliviar gargalo de forma proporcional
- você entende degradação como parte do desenho
Quem faz isso bem parece alguém que resolveria sistema real sem inflar a resposta.
Escala boa começa no fluxo crítico, não no diagrama bonito.
Se a solução veio antes do gargalo, a leitura ainda está rasa.