Case de produção sanitizado
Evoluindo a arquitetura backend de um sistema de compras assistido por IA
Separação entre atendimento de requisições, processamento em segundo plano e integrações empresariais em um sistema Python em produção.
O sistema apoia fluxos de compras que envolvem cotações de fornecedores, comparação de propostas, negociação e automação do processo de compra, com caminhos automatizados e supervisionados por pessoas.
Contexto
À medida que o sistema de compras evoluiu além da primeira versão, os fluxos voltados à API, os processamentos intensivos e as integrações externas passaram a exigir limites mais claros. O trabalho arquitetural buscou manter os serviços de requisição responsivos enquanto suportava fluxos operacionais de longa duração.
Meu papel
Participei da concepção da arquitetura de backend e continuo evoluindo o sistema, com responsabilidade pelos limites entre APIs e serviços, arquitetura de processamento em segundo plano, melhorias de desempenho, manutenção e novas capacidades de backend.
Desafios de engenharia
01
Processamento prolongado acoplado à API
Operações intensivas em recursos consumiam recursos da API e afetavam a disponibilidade dos serviços responsáveis por atender requisições.
02
Confiabilidade de sistemas externos
Integrações empresariais e com ERPs precisavam tolerar falhas transitórias sem permitir que tráfego externo instável se propagasse pela aplicação.
03
Comportamento de recursos em produção
Reinicializações e lentidão recorrentes exigiram investigação por logs da aplicação e métricas de runtime e RAM, incluindo retenção de recursos em cache e processamento de documentos.
Decisões de arquitetura
A decisão central foi separar o processamento de longa duração do ciclo síncrono da API e tornar mais explícitas as responsabilidades entre atendimento de requisições, processamento e integrações.
Mover cargas pesadas para processamento em segundo plano
Operações de longa duração saíram das requisições síncronas da API e passaram para workers. O processamento pôde ser acompanhado de forma assíncrona, com limites de execução separados para atendimento de requisições e cargas intensivas.
Definir limites mais claros entre serviços
Responsabilidades da API, do processamento em segundo plano e do fluxo do agente foram separadas de forma mais deliberada, permitindo adicionar capacidades sem acoplar todas as preocupações ao caminho das requisições.
Fluxo conceitual simplificado
Confiabilidade e integrações
A resiliência dos sistemas externos foi tratada como parte da arquitetura de backend.
- Componentes de integração reutilizáveis para SAP, TOTVS/Datasul e Protheus.
- Novas tentativas para falhas transitórias, limitação de taxa e circuit breakers na comunicação externa.
- Investigação em produção por logs da aplicação e métricas de runtime e RAM.
- Cargas em segundo plano executadas em contêineres na AWS ECS.
Resultado
- Melhor isolamento entre atendimento de requisições e processamento intensivo em recursos.
- Melhoria na disponibilidade e estabilidade dos serviços.
- Limites mais claros para manter e ampliar o backend com novas capacidades.
Julgamento de engenharia
Cargas de longa duração não devem competir desnecessariamente com APIs que atendem requisições. Conforme o sistema cresce, limites entre serviços e resiliência em integrações externas tornam-se decisões arquiteturais. Logs e métricas de runtime são essenciais para diferenciar problemas de lógica de problemas no ciclo de vida de recursos.