Какие методы должен иметь сервис для работы с генерацией картинок

Что проверяют

Умеете ли вы проектировать сервис вокруг долгой и дорогой операции, а не просто перечислить CRUD. Генерация занимает от секунд до минуты и загружает GPU, поэтому следом почти всегда спрашивают: что будет, если клиент отвалится посреди генерации или повторит запрос.

Как отвечать

Начните с того, что синхронная схема «прислал промпт, получил картинку» здесь не работает, и опишите асинхронную модель задач:

• создание задачи: POST /generations принимает промпт, размер, модель, seed, валидирует их Pydantic-схемой и сразу отвечает 202 Accepted с идентификатором задачи;
• статус: GET /generations/{id} возвращает queued, running, succeeded или failed, прогресс и текст ошибки;
• результат: ссылка на файл в S3-совместимом хранилище, обычно presigned URL с ограниченным сроком жизни, а не байты в теле ответа;
• отмена: DELETE /generations/{id}, чтобы не тратить GPU на ненужную задачу;
• история: список генераций пользователя с пагинацией по курсору;
• уведомление: вебхук или SSE вместо частого опроса статуса;
• служебные: список доступных моделей и их лимитов, health и ready для оркестратора.

Внутри: FastAPI принимает запросы, задача уходит в очередь (Celery, RQ или arq поверх Redis или RabbitMQ), GPU-воркеры забирают её, пишут файл в хранилище, а метаданные в PostgreSQL. Отдельно назовите заголовок Idempotency-Key на создании задачи, квоты и rate limit на пользователя, модерацию промпта до постановки в очередь и проверку результата после.

Где спотыкаются

Генерируют прямо в обработчике запроса. Прокси и балансировщики обрывают соединение по таймауту, а воркер веб-сервера всё это время занят одной задачей.

Хранят картинки в базе как bytea. Таблица быстро разрастается, бэкапы тяжелеют, а отдавать файл через приложение дороже, чем прямой ссылкой из хранилища.

Не думают о повторах. Клиент по таймауту шлёт запрос ещё раз, и без ключа идемпотентности вы платите за две одинаковые генерации.