Очереди и лимитеры в портале с кучей внешних AI: где горят деньги

В портале с кабинетом, фоновыми сканами и десятком внешних AI бюджет часто тает быстрее, чем команда успевает спорить про язык. Алексей Меркулов (Fobscraft) разбирает, где реально горят деньги: общая очередь, отсутствие лимитов и учёт «сырых вызовов» вместо успешных результатов. Ниже — порядок сборки контура. Похожую разработку можно заказать через услуги Fobscraft.

Картина, которую все уже видели

Обратите внимание на пятницу. Пользователи жмут «запустить анализ», воркеры берут задачи пачкой, один внешний провайдер отвечает по три секунды, второй лежит. Через час кабинет «висит», а в биллинге провайдера — пик, который никто не планировал.

Первая реакция почти всегда одна: «язык медленный, надо ускорять код». Иногда код и правда тяжёлый. Но чаще продукт уже упирается в чужой лимит и чужой кошелёк: один клиент или один упавший канал съедает общую пропускную способность.

Почему так неочевидно? Потому что в редакторе видно функцию вызова. Не видно, сколько задач уже в брокере, чей тариф их породил и сколько будет стоить повтор после пустого ответа.

Раздельные очереди по провайдерам

Заметьте разницу двух схем. В первой все модели и краулеры стоят в одной общей очереди. В второй — у каждого внешнего канала свой маршрут задач.

В первой схеме медленный или упавший канал тормозит остальные. Во второй вы можете притормозить один контур и оставить продукт живым.

Принцип: изоляция очереди — это изоляция денег и доступности. Цена — чуть больше воркеров и аккуратнее деплой. Обычно это дешевле, чем потерянные сканы в пик сезона.

Два слоя диспетчера

Теперь изменим только одну деталь: как задача попадает к воркеру.

Слой в базе: запись со статусом «в очереди». Пользователь видит честный прогресс, поддержка видит историю, биллинг может сверить факт.

Слой перед брокером: диспетчер забирает пачку, проверяет семафор и квоты, только потом отдаёт задачу воркеру. Так в брокер не уезжает больше работы, чем позволяют лимиты и баланс.

Принцип: очередь без лимитера покупает чужой API на ваши деньги в чужой пользе. Диспетчер — место, где решается, кому сейчас можно тратить.

Что мерить, если смотреть на выручку

Когда очереди и диспетчер стоят, цифры всё ещё могут врать. Счётчик «вызовов API» красивый, но бизнес платит за результат.

• Стоимость успешного результата по каждому провайдеру.
• Доля повторов и пустых ответов — они жрут баланс без ценности.
• Справедливая доля по пользователю или тарифу: один «шумный» клиент не должен съедать чужой лимит.
• Хвост ожидания: человек уйдёт раньше, чем закончится бюджет API.

Принцип: управляйте стоимостью полезного исхода, а не числом сырых запросов в логе.

Публичные инструменты отдельно от кассы

Закрепим на более богатой ситуации. Рядом с кабинетом живёт бесплатный чекер на сайте — удобная воронка лидов. Если он ходит теми же ключами и тем же платёжным ядром, что и платящие клиенты, «подарок» становится дырой в бюджет и в доступы.

Принцип: публичный контур живёт со своими жёсткими лимитами и без доступа к кассе. Ограждение денег здесь важнее красивой схемы сервисов на слайде.

Что вы теперь можете объяснить

Вы можете объяснить, почему «медленный код» часто оказывается общим пулом задач без лимитов. Вы умеете развести очереди по провайдерам, собрать двухслойный диспетчер и мерить стоимость успешного результата. Вы отделяете публичные инструменты от платёжного ядра и видите, где контур охраняет деньги, а где только создаёт видимость занятости воркеров.