{
  "id": 34175,
  "title": "Turning TravelAI.Core Into a Real Production System",
  "url": "https://urgent.news/2026/08/02/turning-travelai-core-into-a-real-production-system",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-08-02T07:42:12.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/aftabkh4n/turning-travelaicore-into-a-real-production-system-3npm"
  },
  "original_language": "en",
  "account": "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.",
  "summary": "TravelAI.Core, a .NET library for searching travel destinations using AI, has evolved from a simple package to a production system. Originally, it only provided a single method to search destinations using various AI providers, but as the system grew, it faced limitations such as blocking performance when one AI provider was slow, difficulty in scaling specific parts of the system, and challenges in debugging issues. To address these issues, the author is upgrading TravelAI.Core into three separate services: an API Service, a Search Service, and an AI Service. Each service will handle a specific task, allowing for independent scaling and fault isolation. Additionally, a message queue (RabbitMQ) will be introduced to decouple service communication, preventing blocking when services are slow or unavailable. Centralized logging will also be implemented using Serilog to simplify issue tracking and debugging. The goal is to create a robust, scalable, and maintainable system that can handle real-world conditions such as network latency, provider outages, and traffic spikes.",
  "key_points": [
    "TravelAI.Core library refactored into three separate services",
    "API Service handles requests, validation, and routing",
    "AI Service isolates communications with AI providers"
  ],
  "editors_take": null,
  "illustration": "https://urgent.news/ill/34175.png",
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}