Keeping AI out of the critical path: why booking always works in Randevoa

Randevoa is a reservation platform for the Azerbaijani market: eight service verticals, real-time slots, prepayment. On top of that sits a voice booking assistant that speaks Azerbaijani — the user talks, the system finds a suitable time and books it.

In a product like this the tempting decision is to put AI everywhere. We did the opposite.

Two different reliability requirements

The booking path and the AI path are not the same class of service:

• Booking — money, calendars and double-booking protection. If it goes down, the business stops.
• AI search and voice — a convenience layer. If it goes down, the user falls back to an ordinary form.

The first layer must not depend on the second. But when both live inside one application, that dependency appears on its own: when the model provider slows down, the request pool fills, threads wait, memory piles up — and booking requests end up unanswered too.

The split

The AI is a separate service. The booking backend (Spring Boot) talks to it only across a clear boundary, and never waits on it:

• The order-creation path makes no synchronous call to the AI service
• If the AI does not answer, search falls back to a plain database query
• The voice assistant runs as its own channel; its result still passes through the same slot engine

That last point matters: the AI does not create the booking itself. It works out what the user wants and hands it to the same slot engine — the one that blocks double booking and handles payment.

This simplifies the safety story too. There is exactly one slot engine and all the rules live there. The AI being "creative" cannot violate any invariant, because the rules are not on its side.

A scaling bonus

The split gave us an unexpected advantage: the two services have completely different resource profiles. The booking backend handles short, frequent transactions. The AI service handles long, heavy, latency-bound ones. They can be scaled separately — adding an instance for one does not make the other more expensive.

Generalising

The rule is simple: keep AI out of your product's critical path. Model providers go down, slow down, rate-limit you and change their response format. None of that should be able to block a customer's money or calendar.

A practical test question: *if I switched the AI service off entirely right now, would the product's core job still work?* If the answer is no, the AI is no longer a feature — it is a single point of failure.