A apresentação "APIs como Infraestrutura: quando integração vira arquitetura", no palco Stadium do TDC São Paulo, abriu com uma provocação à plateia: o que é mais difícil de reverter, trocar o banco de dados de um serviço ou publicar um novo endpoint? Para o palestrante, a resposta é clara: "a decisão de stack é reversível e é local [...] uma decisão de integração, depois que você publicou uma API, essa API está no mundo".
A tese foi ilustrada com um caso real: uma fila de caminhões parada num centro de distribuição por causa da alteração de um contrato de API. A partir daí, a narrativa seguiu em três atos, expostos nos slides como três naturezas de problema: organizacional, arquitetural e técnica — resumidos na frase "não era um bug".
Consumidores ocultos e a burocracia que não protege
No primeiro ato, o cenário era um gateway central tratado como "fonte da verdade" para times consumidores. Mesmo com pipelines de teste e filas de aprovação hierárquica, sempre surgiam consumidores não mapeados — sistemas legados que passaram a usar uma chave de API criada para outra finalidade. Na síntese do palestrante: "a gente tinha a máxima burocracia e a mínima proteção".
O contrato não descreve capacidade
O ponto mais técnico da palestra foi sobre limites de carga. Como mostrou o slide, "o contrato de API descreve formato. Quase nunca descreve capacidade. E é por capacidade que os sistemas morrem". O exemplo veio de um ecossistema com microsserviços em nuvem, altamente escaláveis, chamando um ERP legado que não escala na mesma proporção.
A saída óbvia — limitar por cota e devolver HTTP 429 — foi chamada de armadilha: "você não está controlando de forma graciosa, está simplesmente repassando um erro por capacidade", que pode disparar retries e agravar o problema, especialmente em operações como emissão de nota fiscal. A alternativa defendida é inverter o ponto de controle: criar uma camada absorvente (fila, processamento assíncrono, nivelamento de carga) que aceite as requisições e as entregue no ritmo que o sistema legado aguenta, aumentando latência em troca de resiliência. Como resumiu o palestrante, "o desacoplamento não é binário. Ciclo de vida é possível desacoplar, capacidade não".
Consumo inesperado e efeito cascata no financeiro
O terceiro ato trouxe um caso de pico de consumo numa API de preços vindo de um consumidor sem contrato formal — sem catálogo, sem ownership definido, sem ninguém para conversar quando o problema apareceu. O efeito colateral foi sistêmico: o ERP monolítico, ao concentrar recursos para atender chamadas não previstas, comprometeu inclusive a emissão de notas fiscais. Um slide resumiu a cadeia: processo trava, lead time atrasa, entregas se acumulam, faturamento atrasa, custo sobe — concluindo que "uma linha de contrato quebrada vira uma linha no resultado financeiro".
Lei de Conway como pano de fundo
Fechando essa parte da palestra, a discussão migrou para a Lei de Conway: a arquitetura de sistemas tende a espelhar a estrutura organizacional das equipes que os constroem. Para o palestrante, isso implica que decisões de reorganização societária — tomadas pela liderança executiva — acabam sendo, na prática, decisões de arquitetura. A conclusão prática para quem constrói APIs no Brasil: catálogo de consumidores, contratos de capacidade e governança de mudança não são detalhes de implementação — são, segundo a apresentação, conversa de liderança, não só de arquitetura.