Engenharia de Resiliência: Como superei limitações de Hardware para entregar minha API de IA

Introdução

Desenvolver software nem sempre é um mar de rosas. Às vezes, o maior desafio não é a sintaxe da linguagem, mas sim a infraestrutura que temos disponível. Recentemente, durante o desafio de criar uma API Spring Boot para análise de áudio integrada com o Ollama (modelo Phi-3), deparei-me com um obstáculo comum, mas crítico: falta de espaço em disco e restrições de hardware.

A Batalha: Espaço vs. Inteligência

O modelo Phi-3, embora considerado "light", ainda exige recursos consideráveis de armazenamento e processamento para rodar localmente via Ollama. No meu ambiente de desenvolvimento, o instalador e os modelos pesados entraram em conflito com o armazenamento disponível, impedindo a execução nativa da IA no momento do deploy.

Muitos poderiam desistir ou travar o projeto ali. Mas, como desenvolvedores, o nosso papel é entregar soluções.

A Solução: Arquitetura Desacoplada e Mocking de Performance

Para não interromper o ciclo de entrega e garantir que o backend estivesse pronto, apliquei uma estratégia de Mocking de Serviços.

1. Abstração: Refatorei o meu AudioService para que a lógica de negócio fosse independente do motor de IA.
2. Simulação de Alta Fidelidade: Desenvolvi um serviço que simula a resposta do Phi-3. Isso permitiu validar todo o fluxo da API: desde o upload do arquivo via curl, passando pelo Controller, até à resposta JSON final.
3. Design "AI-Ready": O código foi construído de forma a que, assim que o espaço em disco seja libertado ou a infraestrutura escalada, bastará trocar a implementação do serviço para ligar ao Ollama real.

Teste de Fogo no PowerShell

Com o servidor Spring Boot a rodar em Java 21, utilizei o PowerShell para testar a integração. O resultado? Uma resposta instantânea e precisa:

"Upload concluído e Análise do Phi-3: O arquivo foi processado com sucesso. Sistema pronto para análise em tempo real."

O que aprendi nesta jornada?

1. O código deve ser flexível: Nunca amarres a tua lógica de negócio a uma dependência externa que pode falhar.
2. DevOps é real: Entender o teu ambiente (espaço em disco, PATH, permissões) é tão importante quanto saber Java.
3. Feito é melhor que perfeito (com qualidade): Entregar uma API funcional, documentada e com arquitetura limpa é muito melhor do que um projeto inacabado porque "a IA não rodou".

Conclusão

Este projeto, que agora está no meu GitHub, é um testemunho de que a criatividade técnica supera limitações físicas. Se o Ollama era grande demais para o meu disco hoje, a minha arquitetura foi maior para contornar o problema e entregar o resultado.

E vocês, já tiveram que mudar toda a estratégia de um projeto por causa de limitações de hardware? Vamos trocar experiências nos comentários!