Хардкодинг PRO — Гайд №17. Надёжный ИИ-сервис

Как читать этот гайд

Здесь нет задачи сделать из тебя backend-разработчика. ИИ сам напишет очередь, worker и retry. Тебе нужно понять где может сломаться пользовательский результат и что потребовать от ИИ.

ЧТО ЭТО ↓ ЗАЧЕМ ТЕБЕ ЭТО ↓ ЧТО ДЕЛАЕТ ИИ ↓ КАК ТЫ ПРОВЕРЯЕШЬ

1. Почему прямой запрос ломается 2. Задача, очередь и исполнитель 3. Путь задачи от клика до результата 4. Повторы и ограничения ожидания 5. Защита от дублей 6. Лимит запросов и 429 7. Мониторинг и восстановление 8. Как выбрать инструменты без оверинжиниринга 9. Надёжность и деньги 10. Готовые промпты 11. Непонятные слова 12. Финальная проверка 13. Домашка

1. Почему первый ИИ-сервис ломается

Первый прототип почти всегда выглядит одинаково: пользователь нажал кнопку, backend отправил запрос в AI и просто ждёт ответа.

ПОЛЬЗОВАТЕЛЬ ↓ HTTP REQUEST ↓ AI API ↓ ЖДЁМ ↓ RESULT ↓ ОТВЕТ ПОЛЬЗОВАТЕЛЮ

На демо это кажется идеальным. В production начинается реальная жизнь.

Что может случиться:
вкладка закрылась; интернет пропал; AI отвечает две минуты; VPS перезапустился; внешний сервис вернул 429; процесс упал по памяти; пользователь нажал кнопку ещё раз.

Зачем тебе это знать?
Чтобы не принимать от ИИ архитектуру, которая работает только когда всё идеально.

Что делает ИИ: выносит долгую работу из пользовательского запроса и создаёт отдельную job.

Что проверяешь ты: может ли человек закрыть страницу, вернуться позже и всё равно получить результат.

2. Задача, очередь и исполнитель (Job / Queue / Worker)

JobОдна конкретная задача: «сделать отчёт №123».

QueueОчередь задач, которые ждут обработки.

WorkerИсполнитель, который берёт job и выполняет её.

Зачем тебе?
Теперь жизнь задачи не зависит от одной открытой вкладки и одного длинного запроса.

Когда очередь НЕ нужна

Если операция выполняется быстро, почти никогда не падает и её легко повторить, добавлять Redis только ради модного слова «queue» не нужно.

Главный вопрос владельца: «Что произойдёт, если этот процесс оборвётся посередине?»

3. Как выглядит нормальный путь долгой задачи

Пользователь нажал кнопку ↓ Backend создал JOB #123 ↓ Сохранил её ↓ Сразу вернул пользователю job_id ↓ Queue ↓ Worker ↓ AI / внешний API ↓ Результат сохранён ↓ Status = completed ↓ Пользователь увидел результат

Пользователь не обязан держать вкладку открытой, пока твой AI думает десять минут.

Зачем тебе это знать?
Чтобы у каждой долгой операции существовал понятный жизненный цикл, который можно проверить.

Что делает ИИ: создаёт таблицу jobs или настоящую queue, worker и механизм статусов.

Что проверяешь ты: есть ли у каждой задачи ID, статус и сохранённый финальный результат.

4. Повторы и ограничения ожидания

Повторная попытка (Retry)

Повторная попытка (Retry), то есть повторная попытка после временной ошибки.

Лимит ожидания (Timeout)

Лимит ожидания (Timeout), то есть максимальное время ожидания. Система не должна висеть бесконечно.

Увеличение паузы между попытками (Backoff)

Увеличение паузы между попытками (Backoff) означает, что между повторными попытками мы делаем паузу, причём обычно всё большую.

Попытка 1 → FAIL ждём 2 сек ↓ Попытка 2 → FAIL ждём 4 сек ↓ Попытка 3 → FAIL ждём 8 сек ↓ FINAL FAIL или FALLBACK

Зачем тебе?
Мелкий сбой провайдера не должен сразу превращаться в потерянную задачу. Но бесконечный retry может сжечь деньги.

Нельзя повторять всё подряд. Неверный API key, validation error или неподдерживаемый файл сами по себе не исправятся от десятой попытки.

5. Защита от дублей (Idempotency): один запрос - один эффект

Idempotency — защита от того, чтобы одна и та же операция случайно выполнилась дважды.

Без неё возможны: две оплаты, две генерации за деньги, два заказа, два списания баланса, два письма.

Запрос: order=123 idempotency_key=ABC Первый раз: выполнили → сохранили result Повтор с тем же ABC: вернули старый result НО НЕ ЗАПУСТИЛИ ДЕЙСТВИЕ СНОВА

Зачем тебе это?
Повторная попытка (Retry) и нестабильная сеть могут сами создавать повторные запросы.

Как проверить: попросить ИИ отправить одну опасную операцию дважды и доказать, что платное действие произошло один раз.

6. Лимит запросов (Rate Limit) и ошибка 429

Rate limit — ограничение количества запросов. AI-провайдер не бесконечный кран.

429 Too Many Requests означает: «ты отправляешь слишком много запросов».

Одновременные задачи (Concurrency)

Одновременные задачи (Concurrency) — сколько jobs выполняются одновременно.

100 jobs в Queue НЕ: 100 AI запросов одновременно А: concurrency = 5 ↓ 5 выполняются 95 ждут ↓ следующие заходят по мере освобождения

Зачем тебе?
Один очень активный клиент не должен съесть лимит провайдера для всех остальных.

Что делает ИИ: добавляет concurrency limit, per-user rate limit и обработку 429.

7. Мониторинг и восстановление задач

Наличие очереди ещё не означает, что система надёжная. Нужно видеть, что внутри неё происходит.

Queued jobsСколько задач ждёт.

Oldest job ageСколько ждёт самая старая.

Failed jobsСколько задач окончательно упали.

RetriesСколько повторных попыток происходит.

p95 processingЗа какое время укладываются 95% задач.

Provider errors429, 5xx, timeouts.

Проверка падением и перезапуском

Один из лучших тестов: запустить job, остановить worker посередине и снова запустить. Job не должна исчезнуть.

Главная проверка: «Если сервер перезапустится прямо сейчас, какие пользовательские задачи потеряются?» Ответ должен быть понятным.

8. Как выбрать технологию без оверинжиниринга

Не надо начинать с Redis, Kafka и Temporal только потому, что ты услышал слово «масштабирование».

Postgres jobsДля простого MVP часто достаточно.

PGMQQueue semantics прямо поверх Postgres.

Redis + BullMQХороший вариант для Node.js background jobs.

CeleryПопулярный вариант для Python.

QStash / SQSManaged queue, меньше своей инфраструктуры.

TemporalДля сложных многошаговых процессов.

Полезные ресурсы

Supabase Queues / PGMQОчередь сообщений поверх Postgres. Удобно, если проект уже живёт на Supabase/Postgres.Открыть →BullMQПопулярная очередь для Node.js поверх Redis. Полезна для фоновых jobs, retries, delayed jobs.Открыть →CeleryПопулярная система фоновых задач для Python.Открыть →Upstash QStashManaged background delivery и расписания без постоянного собственного worker.Открыть →AWS SQSКлассическая managed queue с visibility timeout, retries и dead-letter queue.Открыть →TemporalДля сложных, многошаговых workflow, которые должны переживать сбои и продолжаться.Открыть →Stripe IdempotencyХороший эталон защиты от повторного выполнения денежных операций.Открыть →PostgreSQL SKIP LOCKEDПолезный низкоуровневый механизм для queue-like таблиц с несколькими workers.Открыть →

Правило: сначала докажи, что простой вариант перестал справляться. Потом добавляй новый слой.

9. Надёжность напрямую влияет на деньги

Успешная AI-job может включать стоимость модели, storage, worker, базу, очередь и повторные попытки.

AI + storage + worker + queue + database + retries + fallback = реальная себестоимость результата

Опасный сценарий: AI уже выполнил дорогую генерацию, но ответ потерялся. Твой код решил, что задача упала, и запустил её второй раз.

Ограничения расходов

максимальное число retries;
max cost per job;
лимит jobs на пользователя;
daily spend alert;
idempotency;
fallback только в разрешённых сценариях.

Что должен знать владелец: сколько стоит успешная задача и сколько стоит неудачная.

10. Что делает AI, а что остаётся на тебе

AI делаетQueue, worker, schema jobs, Redis/Postgres, retries, monitoring, tests, load test, deploy.

Ты решаешьМожно ли повторять операцию? Какой fallback допустим? Сколько ждать? Сколько можно потратить? Что увидит клиент?

Сильный навык вайбкодера: не писать worker руками, а спросить AI: «Что случится, если прямо здесь упадёт сервер?»

11. Готовые промпты

Это полноценные задания для ИИ-кодера. Они заставляют сначала диагностировать, потом проектировать, потом доказывать.

Промпт 1

Аудит надёжности ИИ-сервиса

Ты работаешь как архитектор надёжности моего ИИ-продукта.

Я не хочу пока ничего менять.

Изучи проект и найди все операции, которые:
- работают дольше 2–3 секунд;
- вызывают внешние AI/API;
- могут упасть по сети;
- могут выполняться параллельно;
- могут списывать деньги;
- нельзя безопасно выполнить дважды.

Для каждой операции объясни простыми словами:
1. Что сейчас происходит от действия пользователя до результата.
2. Что случится, если сервер упадёт посередине.
3. Что произойдёт, если пользователь нажмёт кнопку второй раз.
4. Есть ли timeout.
5. Есть ли retry.
6. Есть ли защита от двойного выполнения.
7. Есть ли rate limit.
8. Где хранится статус задачи.
9. Переживёт ли задача restart.
10. Что увидит пользователь при ошибке.

Верни таблицу:
ОПЕРАЦИЯ | РИСК | ПОЧЕМУ | ЧТО НУЖНО ДОБАВИТЬ | ПРИОРИТЕТ

Не внедряй изменения до отдельного подтверждения.

Промпт 2

Нужна ли здесь очередь вообще?

Проанализируй мой проект и реши, нужна ли очередь.

Не устанавливай Redis, BullMQ, Celery, Temporal или другие инструменты заранее.

Для каждой долгой операции оцени:
- типичное время выполнения;
- максимальное время;
- сколько пользователей могут запускать её одновременно;
- можно ли сразу вернуть пользователю job_id и закончить работу в фоне;
- нужно ли переживать restart;
- нужно ли retry;
- есть ли риск двойного выполнения;
- есть ли внешние rate limits.

Предложи самый простой уровень:
A. Очередь не нужна.
B. Таблица jobs в Postgres.
C. Postgres queue / PGMQ.
D. Redis + BullMQ/Celery.
E. Managed queue, например QStash/SQS.
F. Durable workflow, например Temporal.

Для рекомендации отдельно объясни:
почему следующий более сложный уровень пока НЕ нужен.

Промпт 3

Спроектировать фоновую задачу

Возьми операцию: [ОПИСАНИЕ].

Сейчас она выполняется прямо внутри пользовательского запроса.

Спроектируй безопасный background flow:

USER
→ CREATE JOB
→ SAVE JOB
→ RETURN job_id
→ QUEUE
→ WORKER
→ EXTERNAL AI/API
→ SAVE RESULT
→ NOTIFY USER

Определи:
- какие поля хранит job;
- статусы;
- timeout;
- число retries;
- backoff;
- idempotency key;
- max concurrency;
- rate limit;
- способ уведомления;
- что делать после restart;
- что делать после окончательной ошибки.

Каждый технический термин объясни простым русским языком.

После проектирования покажи минимальную реализацию для моего текущего стека.

Промпт 4

Правильные правила повторных попыток

Проверь все внешние API-вызовы проекта.

Раздели ошибки на три типа:

1. ВРЕМЕННЫЕ
Примеры: сеть, 429, 502, 503, timeout.

2. ПОСТОЯННЫЕ
Примеры: неправильный API key, validation error, неподдерживаемый формат, недостаточный баланс.

3. НЕИЗВЕСТНЫЕ

Для временных ошибок предложи retry policy:
- число попыток;
- интервалы;
- exponential backoff;
- jitter;
- максимальное общее время.

Для постоянных ошибок retry НЕ делай.

Покажи конкретный сценарий:
попытка 1 → ошибка
пауза
попытка 2 → ошибка
больше пауза
попытка 3 → результат или terminal failure.

Не допускай бесконечного retry loop.

Промпт 5

Защита от двойного выполнения

Найди операции, которые опасно выполнить дважды:

- оплата;
- списание баланса;
- платная AI-генерация;
- создание заказа;
- отправка email/Telegram;
- начисление бонусов;
- создание внешнего ресурса.

Для каждой предложи idempotency strategy.

Объясни:
1. Как генерируется idempotency key.
2. Где он хранится.
3. Что происходит при повторном запросе.
4. Как долго ключ живёт.
5. Что происходит при двух параллельных одинаковых запросах.
6. Как тестом доказать, что операция не выполняется дважды.

После внедрения проведи безопасный duplicate test и покажи доказательства.

Промпт 6

Лимит запросов и ошибка 429

Проведи аудит внешних API на rate limits.

Для каждого провайдера найди:
- documented limits, если они опубликованы;
- что означает 429;
- используется ли Повторная попытка (Retry)-After;
- concurrency limits;
- рекомендуемую retry strategy.

Для моего сервиса предложи:
- общий лимит;
- лимит на пользователя;
- max concurrency;
- очередь;
- backoff;
- сообщение пользователю.

Цель:
один активный пользователь не должен съесть весь лимит провайдера для остальных.

Промпт 7

Резервный путь без скрытого ухудшения

Для критичных AI/API зависимостей спроектируй fallback.

Для каждой зависимости ответь:
1. Что является основной системой.
2. Какой fallback возможен.
3. Совместимы ли форматы входа/выхода.
4. Насколько отличается качество.
5. Насколько отличается цена.
6. Когда переключаться.
7. Когда НЕ переключаться.
8. Что увидит пользователь.
9. Как логировать факт fallback.

Нельзя молча выдавать сильно худший результат как будто ничего не произошло.

Сначала предложи архитектуру, затем жди подтверждения.

Промпт 8

Проверка падения и перезапуска

Проведи crash/restart test на безопасной тестовой job.

Сценарий:
1. Создай тестовую job.
2. Начни обработку.
3. Во время обработки останови worker.
4. Запусти worker снова.
5. Проверь, что job не потеряна.
6. Проверь, что результат не продублирован.
7. Проверь статусы в базе/очереди.
8. Проверь logs.
9. Проверь финальное уведомление пользователю.

Верни фактические доказательства PASS/FAIL.

Не считай архитектуру устойчивой, если такой тест не проведён.

Промпт 9

Мониторинг фоновых задач

Создай минимальный monitoring background jobs.

Мне нужны показатели:
- jobs queued;
- jobs running;
- jobs completed;
- jobs failed;
- retry count;
- age of oldest job;
- processing time p50/p95;
- provider errors;
- rate-limit errors;
- cost per job, если возможно.

Добавь понятные alerts:
- очередь растёт слишком долго;
- много failed jobs;
- p95 резко вырос;
- внешний API массово отвечает 429/5xx;
- worker перестал обрабатывать задачи.

Сделай итоговый dashboard так, чтобы его понимал владелец бизнеса, а не только backend-разработчик.

Промпт 10

Безопасная проверка под нагрузкой

Проведи безопасный load test.

НЕ используй реальные дорогие AI-вызовы без ограничения бюджета.

Если возможно, создай mock/stub внешнего AI.

Проверь:
10 jobs,
50 jobs,
100 jobs,
[МОЙ ЦЕЛЕВОЙ ПИК].

Для каждого уровня измерь:
- queued jobs;
- active workers;
- p50/p95 processing time;
- errors;
- memory;
- CPU;
- database connections;
- backlog.

Цель:
найти реальный bottleneck до того, как его найдут пользователи.

Не увеличивай инфраструктуру до появления измеренного ограничения.

Промпт 11

Себестоимость одной задачи

Посчитай себестоимость одной типичной задачи моего сервиса.

Включи:
- AI API;
- повторные попытки;
- fallback;
- storage;
- bandwidth;
- queue/Redis;
- worker/VPS;
- database;
- другие внешние API.

Посчитай сценарии:
1. Успех с первой попытки.
2. Один retry.
3. Три retries.
4. Fallback.
5. Полная ошибка.

Покажи, где возможны двойные списания.

Предложи cost guardrails:
- max attempts;
- max cost per job;
- max jobs per user;
- daily budget alert.

Промпт 12

Финальная приёмка надёжности

Не верь предыдущим сообщениям "готово".

Проведи фактическую acceptance-проверку.

Проверь:
1. Job сохраняется до обработки.
2. Пользователь сразу получает job_id/status.
3. Worker берёт задачу.
4. Результат сохраняется.
5. Временная ошибка вызывает контролируемый retry.
6. Увеличение паузы между попытками (Backoff) реально увеличивает паузу.
7. Permanent error не ретраится бесконечно.
8. Idempotency защищает от дубля.
9. Rate limit соблюдается.
10. 429 обрабатывается.
11. Лимит ожидания (Timeout) работает.
12. Fallback работает только там, где разрешён.
13. Worker restart не теряет job.
14. Failed jobs видны.
15. Monitoring видит backlog.
16. Пользователь получает финальный status.
17. Ограничения расходов работают.

Верни:
QUEUE = PASS/FAIL
RETRY = PASS/FAIL
IDEMPOTENCY = PASS/FAIL
RATE LIMIT = PASS/FAIL
RESTART = PASS/FAIL
MONITORING = PASS/FAIL
COST CONTROL = PASS/FAIL

PASS ставь только тому, что реально проверено.

12. Непонятные слова простыми словами 😄

Термин	Простыми словами
Background task	Задача, которая выполняется в фоне, пока пользователь может закрыть страницу.
Job	Одна конкретная задача, например «сгенерировать отчёт №123».
Queue	Очередь задач, которые ждут обработки.
Worker	Исполнитель, который берёт job из очереди и выполняет её.
Producer	Часть системы, которая создаёт новую job и кладёт её в очередь.
Consumer	Процесс, который забирает job из очереди. Часто это worker.
Повторная попытка (Retry)	Повтор операции после временной ошибки.
Увеличение паузы между попытками (Backoff)	Увеличение паузы между повторными попытками.
Exponential backoff	Пауза растёт: например 2, 4, 8, 16 секунд.
Jitter	Небольшая случайность в паузе, чтобы все workers не повторили запрос одновременно.
Fallback	Запасной способ выполнить задачу, если основной недоступен.
Лимит ожидания (Timeout)	Максимальное время, которое система готова ждать ответ.
Rate limit	Ограничение количества запросов за определённое время.
429	HTTP-код «слишком много запросов».
Одновременные задачи (Concurrency)	Сколько задач выполняется одновременно.
Idempotency	Защита от двойного эффекта при повторном одинаковом запросе.
Idempotency key	Ключ, по которому система узнаёт повтор той же операции.
At-least-once delivery	Очередь гарантирует доставку хотя бы раз, но иногда возможны повторы.
Visibility timeout	Период, когда job временно скрыта от других workers после взятия в работу.
Dead Letter Queue	Отдельное место для задач, которые окончательно не удалось обработать.
Backlog	Накопившийся хвост jobs.
Queue age	Сколько времени самая старая job ждёт выполнения.
Cron	Запуск задач по расписанию.
Scheduler	Механизм планирования будущих задач.
Cache	Быстрое временное хранилище повторно используемых данных.
Redis	Быстрое in-memory хранилище, часто используется для очередей и cache.
PostgreSQL	Реляционная база данных; в небольших системах может хранить и jobs.
PGMQ	Очередь сообщений поверх PostgreSQL.
BullMQ	Популярная очередь для Node.js поверх Redis.
Celery	Популярная система фоновых задач для Python.
QStash	Managed-сервис фоновых HTTP-задач и расписаний.
SQS	Managed-очередь сообщений AWS.
Temporal	Система для долгих, многошаговых и восстанавливаемых workflow.
Durable execution	Выполнение, которое умеет продолжаться после сбоев.
Webhook	HTTP-уведомление от одного сервиса другому.
p95	95% задач выполняются быстрее этого времени.
Monitoring	Наблюдение за состоянием системы.
Alert	Автоматическое уведомление о проблеме.
Graceful degradation	Упрощённый режим работы вместо полного падения.
Circuit breaker	Временная остановка запросов в сервис, который массово падает.

14. Домашка: сломай свой сервис сам

Возьми одну настоящую долгую или платную функцию своего проекта:

AI-генерация или обработка файла или создание отчёта или парсинг или долгий анализ данных

Нарисуй путь от клика до результата.
Реши вместе с AI, нужна ли очередь.
Добавь job_id и статусы.
Настрой timeout и ограниченный retry.
Защити от дублей.
Останови worker посреди тестовой задачи.
Запусти снова и докажи восстановление.
Создай 10–50 mock jobs и посмотри на backlog.
Посчитай себестоимость.

Что принести на разбор: схема, job status, доказательство retry, доказательство crash recovery, duplicate test и одна метрика очереди.

Главная мысль

Надёжность — не Redis и не модная архитектура.

Это способность системы довести обещанную пользователю работу до понятного финала, даже когда отдельные части ошибаются.

ЗАДАЧУ ПРИНЯЛИ ↓ СОХРАНИЛИ ↓ КОНТРОЛИРУЕМ НАГРУЗКУ ↓ ПОВТОРЯЕМ ВРЕМЕННЫЕ ОШИБКИ ↓ НЕ СОЗДАЁМ ДУБЛИ ↓ ПЕРЕЖИВАЕМ RESTART ↓ СОХРАНЯЕМ RESULT ↓ СООБЩАЕМ ПОЛЬЗОВАТЕЛЮ ↓ НАБЛЮДАЕМ И СЧИТАЕМ ДЕНЬГИ

Следующий гайд №17: автономные ИИ-агенты, инструменты, MCP, саб-агенты, оркестрация и подтверждение человеком.

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