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.

What TravelAI.Core looks like today

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.

Splitting it into services

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.

Adding a message queue

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.

Centralized logging

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.

Why bother

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.

What's next

  1. Split the codebase into three services
  2. Add RabbitMQ between them
  3. Wire up Serilog
  4. Test under load locally
  5. Write up the before and after with real numbers

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
NuGet: https://www.nuget.org/packages/TravelAI.Core