This post is an expanded, less academic write-up of my Computer Science capstone project (TCC) at UniFil, built together with Sergio Akio Tanaka: implementing an AI microservice integrated into a CRM, validated with a real case study at a large agribusiness cooperative near Londrina, Brazil.

Problem and motivation

CRM (Customer Relationship Management) systems get a lot more valuable once they incorporate AI — from sentiment analysis on messages to predicting purchase behavior. In practice, though, a lot of corporate CRMs still run on monolithic, tightly-coupled architectures, which makes it hard to bolt AI on top without compromising the existing structure.

That was exactly the situation at the cooperative we used as our reference case: a legacy database that was genuinely hard to interpret on its own, to the point where we regularly needed the cooperative's own team to walk us through its structures.

Research question and hypothesis

The core problem the thesis addressed was: how do you integrate a churn-prediction service — built with machine learning and natural language processing (NLP) — into a CRM, in a way that's decoupled, scalable, and easy to maintain?

The hypothesis was that a microservices architecture — NestJS for the API, Next.js for the front-end — makes that integration efficient, letting the AI service (built independently by Sergio) evolve on its own without putting the rest of the system at risk.

Theoretical grounding

The literature review pulled from three angles: microservices architecture, AI applied to CRM, and legacy system migration. Sharma and Rathore (2022) argue that small, decoupled services make scalability and continuous evolution easier, especially in environments that demand high adaptability — which is exactly the profile of a modern CRM.

Chakraborty (2024), Chauhan (2024), and Hossain (2024) discuss how AI gets applied in this context to analyze historical data, predict churn, and detect signs of dissatisfaction — all of which depend on an architecture that lets you plug those services in without touching the system's core. Ledro, Nosella, and Pozza (2023) reinforce that architectural modularity is a critical success factor for that kind of integration, while Tuusjärvi, Kasurinen, and Hyrynsalmi (2024) document, through a real case study, that migrating legacy systems to microservices takes both technical groundwork and organizational alignment.

Methodology

The project combined a systematic literature review with hands-on development:

• Literature review on Scopus, using a structured boolean search string combining terms like deployment, microservices, CRM, and performance optimization, followed by bibliometric filtering with the Bibliometrix package (R) to prioritize studies by relevance, publication year, and topical fit.
• Building a minimal version of the system, simulating the real integration between the CRM and the AI service through microservices.
• Validating it against a real use case, with weekly meetings with the cooperative to align deliverables, evaluating criteria like performance, coupling, maintainability, and scalability.

Architecture

The solution was containerized with Docker and deployed on an Ubuntu server, split into five independent services:

• CRM API (NestJS/Node.js): exposes entities like Cooperados (members), Culturas (crops), Commodities, Unidades (units), Safras (harvest seasons), Users, and AI_data, each with its own service and controller layer.
• Front-end (Next.js + React): screens built with shadcn/ui, consuming the API to present data to the user.
• AI service (Python 3.12): runs the prediction algorithm built for the cooperative, isolated from the rest of the stack.
• RabbitMQ: messaging between services.
• Redis: caching layer.
• PostgreSQL: internal database for authentication and access control.

Splitting things this way paid off in three concrete ways: business rules stayed isolated (making them easier to evolve), coupling with the cooperative's legacy system dropped, and testing and maintenance got more predictable — on top of laying groundwork for observability through structured logs, which matters a lot once you're juggling multiple integrations.

Data and security

The data the API consumed came from a view on a Microsoft SQL Server database provided by the cooperative itself, accessed over VPN and limited to business hours and Saturdays. The system kept two databases: that cooperative view, and an internal one (PostgreSQL, inside Docker) for access-control data.

Authentication used predefined email/password credentials, with route protection via React's native middleware, a POST request to the API, and a session cookie written on success — or a JSON error surfaced through a toast notification on failure. Public access to the screens was restricted to predefined emails and protected by Cloudflare, and the API was documented through Swagger. Access reserved for the cooperative itself sat behind a FortiClient VPN, using credentials the cooperative provided.

Screens and features

The main dashboard brings together a revenue overview by harvest season, new members over time, and a breakdown of members by category — filterable by season, with hover tooltips for more detail. A second screen complements that view with the least active units and the total number of active versus inactive members per season, also filterable.

Results

The microservices split delivered the decoupling we were after, which showed up directly in easier maintenance and in how straightforward it became to add or change features. At the first validation meeting with the cooperative's stakeholders, feedback on the system's simplicity and usefulness was positive — and that held up through the final months of the research, when we presented the application's first results.

Limitations and future work

Three limitations stand out. First, dependency on the AI service built by another team member: if it fails, it directly hits the performance of the whole integration. Second, the overhead of managing microservices itself — communication between modules, orchestration, and monitoring all add real complexity to the project. Third, the system isn't wired into the cooperative's real production CRM yet: it runs against an anonymized replica of the data, on a legacy structure that isn't always trivial to interpret without the cooperative's help.

It's worth being clear that the thesis scope was the integration with the AI service, not building or training the model itself — that part was Sergio's. As a next step, there's already a plan to extend the project to other interested companies, each with their own business rules, though carried forward by only part of the original team.