Масова відправка документів на підписання з трекінгом та нагадуваннями

При злитті двох компаній потрібно розіслати 5000 трудових договорів за 48 годин. Ручна відправка потребує 10 співробітників на тиждень — з помилками, втраченими листами та нервотрепкою. Ми автоматизуємо цей процес: завантаження CSV, генерація персоналізованих PDF, відправка через чергу завдань, відстеження статусів та автоматичні нагадування. Нижче — архітектура, яка витримає навантаження 10K+ документів без падіння.

Які проблеми вирішуємо?

Генерація тисяч документів без зависання сервера. Синхронна генерація вб'є сервер — використовуємо чергу завдань на BullMQ. Кожен документ генерується окремим воркером, паралельність до 10. Навіть при піку в 5000 документів система залишається чуйною.

Rate limiting email-провайдерів. Resend дає 100 листів на секунду, Postmark — стільки ж. Для batch в 10K листів ми впроваджуємо throttling в черзі: відправка йде зі швидкістю 100–200 листів на хвилину, щоб не потрапити в блокування. Таймаути та повторні спроби — обов'язкові.

Відсутність підписання у частини отримувачів. Автоматичні нагадування через 2 та 4 дні. Налаштовувана кількість (до 3). Дашборд показує, хто не відкрив лист, і дозволяє надіслати нагадування вручну.

Як ми це робимо?

Типовий стек: PostgreSQL + Redis + BullMQ + Node.js (NestJS) + Puppeteer для PDF. Воркери розгорнуті в Docker на окремому інстансі. Код зберігається в GitLab CI, деплой на AWS ECS.

Кейс: для маркетплейсу впровадили масову відправку актів виконаних робіт. Щомісяця 15 000 актів. Раніше бухгалтерія витрачала 3 дні на розсилку через Outlook. Після впровадження — 30 хвилин. Помилки скоротилися з 5% до 0.2%.

Процес роботи

1. Аналітика. Збираємо вимоги: обсяг, шаблони документів, інтеграції (CRM, бухгалтерія).
2. Проектування. Схема БД, черга завдань, API, сторінка підписання.
3. Реалізація. Розробка модулів: завантаження CSV, генерація PDF, відправка, дашборд.
4. Тестування. Навантажувальне тестування з 10K документів, сценарії помилок.
5. Деплой. На сервер клієнта або хмару. Налаштування CI/CD, моніторинг (Sentinel, Grafana).

Чому черга завдань краща за синхронну генерацію?

Синхронна генерація 5000 PDF викличе тайм-аут сервера. Черга BullMQ з воркерами (паралельність 10) обробляє документи поступово, не блокуючи запити. Redis зберігає прогрес. Якщо воркер впав — завдання автоматично перезапускається. Це дає надійність та масштабованість.

Як працює черга в коді?

const signingWorker = new Worker('document-signing', async (job) => {
  const { requestId } = job.data;
  const request = await db.signingRequests.findByPk(requestId);

  try {
    await db.signingRequests.update(requestId, { status: 'generating' });

    const pdfBytes = await documentGenerator.generate(
      request.template, request.templateData
    );

    const document = await documentStorage.store(pdfBytes, {
      batchId: request.batchId,
      requestId: request.id,
    });

    const signingUrl = `${process.env.APP_URL}/sign/${request.signingToken}`;

    await emailService.send({
      to: request.recipientEmail,
      subject: 'Документ ожидает вашей подписи',
      template: 'signing-invitation',
      data: {
        recipientName: request.recipientName,
        documentName: request.template.name,
        signingUrl,
        expiresAt: request.expiresAt,
      },
    });

    await db.signingRequests.update(requestId, {
      status: 'sent',
      documentId: document.id,
      sentAt: new Date(),
    });

    await db.signingBatches.increment(request.batchId, 'sent_count');
  } catch (error) {
    await db.signingRequests.update(requestId, {
      status: 'failed',
      errorMessage: error.message,
    });
    await db.signingBatches.increment(request.batchId, 'failed_count');
  }
}, {
  concurrency: 10,
  connection: redisConnection,
});

Обмеження та надійність

Email-провайдери блокують при перевищенні лімітів. Ми налаштовуємо чергу з паузою між відправками. Використовуємо виділені сервери відправки (SMTP-ретранслятори) та відстежуємо статуси листів (bounce, spam). Гарантуємо доставку 99%.

Автоматичні нагадування

Якщо отримувач не підписав, автоматика надсилає нагадування на 2-й та 4-й день. На 7-й день — позначка "прострочено" та сповіщення менеджеру. У дашборді можна надіслати повторний лист з новим посиланням. Налаштовуваний ліміт нагадувань — від 0 до 5.

async function sendSigningReminders() {
  const pending = await db.signingRequests.findAll({
    status: 'sent',
    reminderCount: { lt: 3 },
    sentAt: { lt: subDays(new Date(), 2) },
    expiresAt: { gt: new Date() },
  });

  for (const request of pending) {
    const lastReminderAt = request.lastReminderAt || request.sentAt;
    const daysSinceLastReminder = differenceInDays(new Date(), lastReminderAt);

    if (daysSinceLastReminder >= 2) {
      await emailService.sendReminder(request);
      await db.signingRequests.update(request.id, {
        reminderCount: request.reminderCount + 1,
        lastReminderAt: new Date(),
      });
    }
  }
}

Порівняння ручної та автоматичної розсилки

Також додаємо порівняння за швидкістю: автоматична розсилка в 20 разів швидша за ручну (40 годин проти 2).

Модель даних

CREATE TABLE signing_batches (
  id              UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  name            VARCHAR(500),
  template_id     UUID REFERENCES document_templates(id),
  initiated_by    UUID REFERENCES users(id),
  total_count     INT NOT NULL,
  sent_count      INT DEFAULT 0,
  signed_count    INT DEFAULT 0,
  failed_count    INT DEFAULT 0,
  status          VARCHAR(50) DEFAULT 'pending',
  -- pending → processing → completed / partially_failed
  deadline_at     TIMESTAMPTZ,
  created_at      TIMESTAMPTZ DEFAULT NOW()
);

CREATE TABLE signing_requests (
  id              UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  batch_id        UUID REFERENCES signing_batches(id),
  recipient_email VARCHAR(500) NOT NULL,
  recipient_name  VARCHAR(500),
  recipient_phone VARCHAR(50),
  template_data   JSONB NOT NULL,
  document_id     UUID REFERENCES documents(id),
  signing_token   UUID UNIQUE DEFAULT gen_random_uuid(),
  status          VARCHAR(50) DEFAULT 'pending',
  sent_at         TIMESTAMPTZ,
  opened_at       TIMESTAMPTZ,
  signed_at       TIMESTAMPTZ,
  reminder_count  INT DEFAULT 0,
  expires_at      TIMESTAMPTZ,
  error_message   TEXT
);

Завантаження та валідація CSV

async function processBatchUpload(file: Express.Multer.File, templateId: string) {
  const records = await parseCSV(file.buffer, { headers: true });
  const template = await db.documentTemplates.findByPk(templateId);
  const requiredFields = extractTemplateVariables(template.content);

  const errors: ValidationError[] = [];
  const validRows: RecipientRow[] = [];

  records.forEach((row, index) => {
    const rowErrors = [];

    if (!row.email || !isValidEmail(row.email)) {
      rowErrors.push(`Строка ${index + 2}: некорректный email`);
    }

    for (const field of requiredFields) {
      if (!row[field]) {
        rowErrors.push(`Строка ${index + 2}: отсутствует поле "${field}"`);
      }
    }

    if (rowErrors.length > 0) {
      errors.push(...rowErrors);
    } else {
      validRows.push(row);
    }
  });

  return { valid: validRows, errors, totalRows: records.length };
}

Сторінка підписання за токеном

Отримувач переходить за посиланням https://app.example.com/sign/{token} — авторизація не потрібна, доступ тільки за токеном:

app.get('/sign/:token', async (req, res) => {
  const request = await db.signingRequests.findOne({
    signingToken: req.params.token,
    status: { not: ['expired', 'signed', 'declined'] },
  });

  if (!request) return res.redirect('/sign/invalid');
  if (request.expiresAt < new Date()) {
    await db.signingRequests.update(request.id, { status: 'expired' });
    return res.redirect('/sign/expired');
  }

  if (!request.openedAt) {
    await db.signingRequests.update(request.id, { openedAt: new Date() });
  }

  res.render('signing-page', { request, document: request.document });
});

Дашборд моніторингу batch

Прогрес-бар: відправлено/підписано/не відкрито/прострочено. Таблиця з фільтрами за статусом. Експорт у CSV. Кнопка «Надіслати нагадування» для вибраних отримувачів.

Орієнтовні строки

Що входить в роботу?

Зв'яжіться з нами для оцінки вашого проєкту. Отримайте консультацію з автоматизації підписання документів.

Послуги бекенд-розробки: production-grade надійність

На production-сервері о 3:14 ночі черга Laravel Jobs перестала оброблятися — 40 000 необроблених завдань у Redis. Причина: worker упав через memory leak у статичній змінній Eloquent observer, supervisor не перезапустив через misconfigured stopwaitsecs. Ми розбирали такий інцидент на проекті з 500 RPS: діагностика 4 години, фікс — 20 хвилин. Щоб ви не втрачали гроші, пропонуємо послуги бекенд-розробки з акцентом на production-grade надійність — 10+ років досвіду, 50+ проектів, 5 років на ринку. Оцінимо ваш проект за 2 дні.

Які проблеми вирішуємо

N+1 запити: головний вбивця швидкості

N+1 — найпоширеніша причина повільних сторінок у Laravel-додатках. Стандартна історія: сторінка працювала нормально на dev з 10 записами, на production з 10 000 — 8-секундне завантаження.

Laravel Debugbar у dev-оточенні показує кількість запитів. Більше 20 — сигнал для audit.

Model::preventLazyLoading(! app()->isProduction());

Telescope для профілювання: логує всі запити, jobs, mail, notifications з деталізацією. Після впровадження eager loading час завантаження сторінки падає з 8 с до 0.3 с — у 27 разів.

Memory leak у статичних змінних

У Laravel Octane або Swoole додаток тримається в пам’яті між запитами. Статичні змінні не скидаються — призводять до неконтрольованого росту пам’яті. Використовуємо defer-функції та контейнерні біндинги для коректного скидання стану.

Неправильний connection pool

Rails, Laravel, Django відкривають нове з'єднання PostgreSQL на кожен PHP/Python процес. 100 воркерів — 100 з'єднань. PostgreSQL деградує від 200+ активних з'єднань через overhead на управління.

PgBouncer у transaction pooling: 1000 воркерів → 20–50 реальних з'єднань. Це знижує latency на 40% та зменшує витрати на хостинг на 30% — при середній вартості хостингу $2,000/міс економить $600/міс. GIN-індекс для JSONB до 100 разів швидший за B-tree при пошуку.

Як Octane справляється з високим навантаженням?

Laravel Octane (RoadRunner або Swoole) прибирає overhead bootstrap на кожен HTTP-запит. Приріст: 3–8x на синтетичних бенчмарках, 2–4x на реальних додатках. Важливо: не зберігати стан у статичних змінних — застосовуємо це на проектах >1000 RPS.

Як PostgreSQL допомагає уникнути повільних запитів?

Використовуємо composite indexes для WHERE + ORDER BY, partial indexes для фільтрів з високою селективністю, GIN-індекси для JSONB та full-text search. to_tsvector + GIN замість LIKE '%query%' — запобігає seq scan навіть на мільйонах записів. Аналізуємо плани через EXPLAIN ANALYZE та pg_stat_statements.

Як обрати стек для вашого проекту?

Node.js виправданий для realtime: Laravel публікує події в Redis Pub/Sub, Node.js підписується та транслює клієнтам. Go — для goroutines (10k з'єднань на сервер — норма), але розробка повільніша, ніж Laravel.

Чому Redis критичний для продуктивності?

Redis виконує кілька ролей:

Redis Cluster для горизонтального масштабування, Sentinel для автоматичного failover. Замовте консультацію щодо оптимізації Redis для вашого проекту.

Що входить в роботу під ключ

• Архітектурне проектування (документація API, схема БД, діаграма сервісів)
• Реалізація за узгодженим ТЗ з code review
• Налаштування CI/CD (GitHub Actions, Docker), моніторингу (Sentry, Grafana), алертингу
• Навантажувальне тестування (k6, wrk) зі звітом
• Передача вихідних кодів, доступів, інструкція з деплою
• Навчання команди замовника (2–3 сесії)
• Гарантійна підтримка 1 місяць після здачі

Орієнтири по термінах

Вартість розраховується індивідуально після аналізу вимог до навантаження, інтеграцій та бізнес-логіки. Зв'яжіться з нами для безкоштовного аудиту вашого поточного backend — отримайте план оптимізації за 2 дні. Замовте консультацію та дізнайтеся, як знизити витрати на інфраструктуру на 30% без втрати продуктивності.