Turning TravelAI.Core Into a Real Production System

A developer is upgrading TravelAI.Core, a .NET library for AI-powered travel destination search, into a production-ready system. The upgrade breaks the library into three independent services—API, Search, and AI—connected via RabbitMQ, with centralized logging through Serilog. The developer aims to address scalability and reliability issues that arise when a library is used in real-world applications.

A few months ago I published TravelAI.Core, a .NET library for searching travel destinations using AI. Version 2.0.0 shipped with support for OpenAI, Anthropic, Azure OpenAI, and Ollama. It works. People are using it. But it's still just a library. One package, doing one job, called directly from your code. That's not how production systems work. So I'm upgrading it. You install the package, call a method, and it searches destinations using whichever AI provider you configured. Simple, useful for small projects. Plug it into a real product with real traffic and a few problems show up fast: One process does everything. Search, AI calls, and business logic all run in the same place. If the AI provider is slow, your whole app waits. You can't scale just the search part without scaling everything else. And if something breaks, you're digging through console output trying to figure out which call caused it. These aren't bugs. They're what happens when a library grows past its original scope. I'm breaking TravelAI.Core into three pieces. API Service - the front door. Takes requests, validates them, passes work along. It doesn't do the heavy lifting itself. Search Service - handles destination search and filtering. Can scale independently if search traffic grows without touching the AI side. AI Service - handles all calls to OpenAI, Anthropic, Azure, or Ollama. Isolated so a slow or unavailable provider doesn't freeze everything else. Each service does one job. Instead of the services calling each other directly, I'm putting RabbitMQ between them. Here's why it matters. If the API service calls the AI service directly and the AI service is slow, the API service waits. With a queue, the API service sends a message and moves on. The AI service picks it up when it's ready. Nothing blocks. It also means if the AI service crashes and restarts, no requests get lost. They sit in the queue until the service comes back up. I'm adding Serilog so every service writes to one place. This sounds small. It isn't. When something breaks in a multi-service system, the hard part usually isn't fixing the bug. It's working out which service caused it. Scattered logs across three consoles turn a five-minute investigation into an hour of guessing. A single library shows you can write clean code. A multi-service system with a message queue and centralized logging shows you can design something that holds up under real conditions: slow networks, provider outages, traffic spikes. And it costs nothing to build. Everything runs locally through Docker. TravelAI.Core started as a simple idea. It's turning into something more useful: a real example of how to structure a system that doesn't fall over. More updates as this progresses. GitHub: https://github.com/aftabkh4n/TravelAI.Core https://github.com/aftabkh4n/TravelAI.Core NuGet: https://www.nuget.org/packages/TravelAI.Core https://www.nuget.org/packages/TravelAI.Core