Как бы вы изменили продуктовый и технический подход к генерации отчётов, чтобы пользователь не ждал синхронного формирования большого PDF?

Синхронная генерация большого PDF — это классический антипаттерн: HTTP-запрос держит соединение открытым минуты, таймауты прокси и браузера срабатывают, а сервер тратит память и CPU на одну задачу. Продуктово пользователь тоже страдает: он не понимает, идёт ли процесс, и не может закрыть вкладку.

Продуктовый подход

• Пользователь нажимает «Сформировать отчёт» и сразу видит подтверждение: «Отчёт формируется, мы пришлём ссылку».
• В интерфейсе появляется раздел «Мои отчёты» со статусами: в очереди, в работе, готов, ошибка.
• Уведомление приходит по email, в push или в самом приложении, когда файл готов.
• Можно отменить задачу или перезапустить её при ошибке.

Технический подход

API-эндпоинт перестаёт быть «тяжёлым»: он только валидирует параметры, создаёт запись задачи в БД со статусом pending и кладёт сообщение в очередь (RabbitMQ, Kafka, Redis, SQS). Отдельный воркер забирает задачу, генерирует PDF, загружает его в S3 и обновляет статус на done со ссылкой.

// POST /reports
const job = await db.jobs.create({ status: 'pending', params });
await queue.publish('pdf.generate', { jobId: job.id, params });
return res.status(202).json({ jobId: job.id });

// worker
queue.subscribe('pdf.generate', async ({ jobId, params }) => {
  await db.jobs.update(jobId, { status: 'processing' });
  const pdf = await renderPdf(params);
  const url = await s3.upload(pdf);
  await db.jobs.update(jobId, { status: 'done', url });
  await notifyUser(jobId);
});

Дополнительные практики

• Идемпотентность: повторная доставка сообщения не должна создавать дубликаты.
• Retry с backoff и dead-letter queue для сбоев.
• Ограничение параллелизма воркеров, чтобы не перегрузить БД или рендер-сервис.
• Прогресс-бар через WebSocket или polling статуса.

Итог: асинхронная генерация отчётов через очередь и воркеры снимает нагрузку с веб-слоя, делает UX предсказуемым и позволяет масштабировать обработку независимо от API. Применять стоит всегда, когда операция длится дольше пары секунд или требует много ресурсов.