Sanitized production case
Evolving the Backend Architecture of an AI-Assisted Procurement System
Separating request handling, background processing and enterprise integrations in a production Python system.
The system supports procurement workflows involving supplier quotations, proposal comparison, negotiation and purchase-flow automation, with automated and human-supervised paths.
Context
As the procurement system grew beyond its first version, API-facing flows, resource-intensive processing and external integrations needed clearer boundaries. The architectural work focused on keeping request-serving services responsive while supporting long-running operational workflows.
My role
I co-designed the backend architecture and continue to evolve the system, with responsibility for API and service boundaries, background-processing architecture, performance improvements, maintenance and new backend capabilities.
Engineering challenges
01
Long-running work coupled to API requests
Resource-intensive operations were consuming API resources and affecting the availability of request-serving services.
02
External-system reliability
Enterprise and ERP integrations had to tolerate transient failures without allowing unstable external traffic to propagate through the application.
03
Production resource behavior
Recurring restarts and slowdowns required investigation through application logs and runtime and RAM metrics, including resource-retention behavior in caching and document processing.
Architecture decisions
The central decision was to separate long-running processing from the synchronous API lifecycle and make responsibilities between request handling, processing and integration boundaries more explicit.
Move heavy work to background processing
Long-running operations moved from synchronous API requests into background workers. Processing could be tracked asynchronously while request-serving and resource-intensive workloads used separate execution boundaries.
Define clearer service boundaries
API-facing responsibilities, background processing and agent-workflow responsibilities were separated more deliberately as the system evolved, allowing new capabilities to be added without coupling every concern to the request path.
Simplified conceptual flow
Reliability and integrations
External-system resilience was treated as part of backend architecture rather than an afterthought.
- Reusable integration components for SAP, TOTVS/Datasul and Protheus.
- Retries for transient failures, rate limiting and circuit breakers around external communication.
- Production investigation through application logs and runtime and RAM metrics.
- Containerized background workloads deployed on AWS ECS.
Result
- Improved isolation between request handling and resource-intensive processing.
- Improved service availability and stability.
- Clearer boundaries for maintaining and extending the backend with new capabilities.
Engineering judgment
Long-running workloads should not compete unnecessarily with request-serving APIs. As a system grows, service boundaries and resilience around external integrations become architectural concerns. Production logs and runtime metrics are essential for distinguishing application-logic issues from resource-lifecycle problems.