Turning TravelAI.Core Into a Real Production System

A few months ago, the author published TravelAI.Core, a .NET library designed for searching travel destinations using AI. Version 2.0.0 introduced support for multiple AI providers such as OpenAI, Anthropic, Azure OpenAI, and Ollama. Nevertheless, the library remains a standalone package with a single function called directly within user code.

This approach is not suitable for production systems. There are several issues with a single-process system that handles search, AI calls, and business logic within the same place. When the AI provider is slow, the entire application stalls. Scaling just the search component is not feasible without scaling the entire system. Additionally, pinpointing the source of a failure becomes challenging as one has to sift through console output to identify the problematic call.

The library's scope has outgrown its original design. To address these issues, the author plans to refactor TravelAI.Core into three separate services. The first service, the API Service, will serve as the entry point, taking requests, validating them, and routing work to other services. Rather than performing the heavy lifting itself, this service will remain a thin wrapper.

The second service, the Search Service, will take care of destination search and filtering. It will be able to scale independently if the demand for search functionality increases without affecting the AI-related components. The final service, the AI Service, will handle all communications with AI providers such as OpenAI, Anthropic, Azure OpenAI, and Ollama.

Isolating this service will prevent a slow or unresponsive provider from affecting the performance of other parts of the system. A message queue, RabbitMQ, will be introduced to decouple the services further. Instead of direct calls between services, messages will be sent to the queue. The API service will dispatch a message and proceed without waiting for the AI service's response.

When the AI service becomes available again, it will process the queued messages. This approach ensures that a slow or unavailable AI provider won't cause the entire system to freeze. Additionally, RabbitMQ will prevent message loss if the AI service crashes and restarts. To facilitate troubleshooting, centralized logging using Serilog will be implemented.

This way, all services will write their logs to a single destination, making it easier to identify the source of a problem. Finally, the author stresses that building this multi-service system with a message queue and centralized logging doesn't cost anything as everything runs locally through Docker. The next steps involve splitting the codebase into three services, integrating RabbitMQ, setting up Serilog, testing the system under load locally, and documenting the improvements with real-world metrics.

The project began as a simple idea, but it is evolving into a valuable example of how to structure a system that can handle real-world challenges without collapsing under pressure. Further updates will be shared as the project progresses. Source code can be found on GitHub: https://github.com/aftabkh4n/TravelAI.Core. The library is also available on NuGet: https://www.nuget.org/packages/TravelAI.Core.