No meu último artigo, “O Casamento Perfeito: IA + Go”, falei bastante sobre como comecei a enxergar Python e Go não como rivais, mas como tecnologias complementares dentro de uma arquitetura moderna para aplicações de IA. A ideia principal era justamente separar responsabilidades: Python focado na inteligência e Go assumindo a infraestrutura de alta performance. Desde então, comecei a tirar essa arquitetura do papel e transformar tudo em um MVP funcional. E foi exatamente nesse momento que duas peças começaram a ganhar um peso muito maior do que eu imaginava inicialmente: o gRPC e os contratos .proto.

Quando estamos desenhando arquitetura no papel, é muito fácil resumir comunicação entre serviços como “uma API chama a outra”. Só que, na prática, a realidade é muito diferente. Principalmente quando você começa a trabalhar com aplicações de IA que precisam responder rápido, manter conexões abertas, fazer streaming de dados e lidar com múltiplas chamadas concorrentes ao mesmo tempo. Nesse cenário, comecei a perceber que REST começava a gerar um overhead desnecessário para aquilo que eu estava tentando construir. Não porque REST seja ruim — longe disso — mas porque talvez ele não tenha sido pensado para esse tipo de comunicação extremamente intensa entre serviços internos.

Foi aí que comecei a mergulhar mais profundamente no gRPC.

O que começou a me incomodar no REST

Uma das coisas que mais comecei a observar no desenvolvimento do MVP foi que boa parte da comunicação entre os serviços não precisava da flexibilidade que normalmente usamos em APIs públicas. O backend em Go não precisava “descobrir” como consumir o serviço de IA em Python. Ele precisava apenas enviar dados da forma mais rápida, previsível e eficiente possível. E isso muda completamente a perspectiva da arquitetura.

No REST tradicional, existe muito texto trafegando. JSON é extremamente prático para desenvolvimento, debug e integração, mas também é relativamente pesado. Cada request carrega um overhead considerável de serialização, parsing e estrutura textual. Em aplicações comuns isso dificilmente vira problema. Mas quando você começa a pensar em centenas ou milhares de chamadas internas acontecendo constantemente, principalmente em streaming de respostas de IA, o impacto começa a aparecer.

E não é só sobre performance.

Existe também um problema silencioso de previsibilidade. Em muitos projetos REST, o contrato entre serviços acaba ficando “implícito”. Você documenta endpoints, define payloads, mas ainda depende muito de convenção, alinhamento entre equipes e disciplina de implementação. Conforme sistemas crescem, isso começa a gerar uma quantidade absurda de inconsistências pequenas que vão se acumulando ao longo do tempo.

Foi exatamente aí que os contratos .proto começaram a fazer muito sentido para mim.

O poder real do contrato .proto

A primeira impressão que tive quando comecei a estudar protobuf foi achar que era apenas uma forma diferente de serializar dados. Mas na prática ele acaba se tornando muito mais do que isso. O arquivo .proto vira literalmente o contrato oficial entre os serviços.

E isso muda bastante a dinâmica do desenvolvimento.

Ao invés de cada serviço “interpretar” payloads JSON de forma mais flexível, tudo passa a ser explicitamente definido. Quais campos existem, quais tipos são aceitos, quais respostas podem retornar, quais métodos estão disponíveis. Não existe ambiguidade. O contrato é único e compartilhado entre todas as partes do sistema.

No MVP que comecei a desenvolver, isso começou a gerar uma clareza arquitetural muito interessante. O serviço em Go não precisa conhecer detalhes internos da IA. Ele apenas conhece o contrato. Sabe exatamente quais mensagens enviar, quais estruturas receber e quais métodos chamar. O mesmo vale para o serviço em Python. Ele não precisa entender nada sobre gerenciamento de conexão, sessão ou streaming WebSocket. Ele apenas responde ao contrato definido.

Essa separação começou a deixar o sistema absurdamente mais organizado.

E talvez uma das coisas mais interessantes disso tudo seja o fato de que o .proto praticamente força uma disciplina arquitetural saudável. Você começa a pensar melhor sobre os limites do sistema antes mesmo de escrever código. Porque qualquer alteração no contrato impacta diretamente a comunicação entre os serviços. Isso cria uma preocupação muito maior com compatibilidade, versionamento e clareza das interfaces.

Na prática, o contrato deixa de ser documentação e passa a ser parte central da arquitetura.

Performance é só uma parte da história

Muita gente fala de gRPC focando apenas em velocidade. E sim, a diferença de performance existe. Principalmente pela utilização de protobuf e HTTP/2. A comunicação fica muito mais eficiente e o consumo de banda reduz bastante em comparação com JSON tradicional. Mas sinceramente? Conforme comecei a implementar isso no MVP, percebi que o maior ganho talvez nem esteja na performance bruta.

O maior ganho está na previsibilidade.

Quando você trabalha com IA em tempo real, previsibilidade vira quase uma obsessão. Você precisa saber como o sistema vai se comportar sob carga. Precisa reduzir ao máximo as variáveis invisíveis da infraestrutura. Precisa garantir que os serviços conversem da forma mais consistente possível. E quanto mais enxuto e explícito é o canal de comunicação, mais controle você ganha sobre o sistema.

Hoje começo a entender que gRPC não é apenas uma escolha de tecnologia. É quase uma escolha de filosofia arquitetural. Você abre mão de parte da flexibilidade em troca de contratos muito mais rígidos, comunicação mais eficiente e um ecossistema muito mais previsível entre serviços internos.

E para sistemas distribuídos de IA, isso parece fazer cada vez mais sentido.

Tirando a arquitetura do campo da teoria

Uma das maiores diferenças entre estudar arquitetura e começar a construir um MVP real é que os problemas deixam de ser abstratos. Tudo começa a ter consequência prática. Latência deixa de ser gráfico bonito e vira experiência do usuário. Contratos mal definidos deixam de ser detalhe técnico e viram erro em produção. Concorrência deixa de ser conceito e vira gargalo.

Talvez por isso minha visão sobre essa combinação entre IA + Go tenha amadurecido bastante desde o primeiro artigo.

Antes eu enxergava principalmente o potencial da separação entre inteligência e infraestrutura. Agora começo a perceber que a forma como essas partes se comunicam é tão importante quanto a separação em si.

E honestamente? Quanto mais avanço nesse MVP, mais acredito que o futuro das aplicações de IA não será construído apenas em cima de modelos mais inteligentes, mas em cima de arquiteturas mais sólidas, previsíveis e sustentáveis.