Гарантоване збереження даних форм у базу та email на Laravel

За статистикою, до 30% заявок з форм зворотного зв'язку втрачаються через збої пошти або неправильне налаштування. Менеджери витрачають час на ручну перевірку, а клієнти йдуть до конкурентів. Правильна архітектура — зберігати дані в базу й одночасно надсилати email. Такий підхід гарантує збереження кожної заявки та прискорене повідомлення. Наша команда реалізувала цю схему для більш ніж 50 проєктів, включаючи інтернет-магазин з 5000 заявок на день — після впровадження втрати заявок знизилися до нуля.

У цій статті ми покажемо, як реалізувати цю схему на Laravel 11 з використанням черг і механізмів повторної відправки. Ви дізнаєтеся, як налаштувати валідацію, захист від спаму та дашборд для перегляду заявок.

Чому варто зберігати дані форми в базу та надсилати email?

Спільне використання бази та email дає подвійну перевагу: надійність зберігання в 2 рази вища, ніж при використанні тільки email, а швидкість повідомлення залишається миттєвою. Черга з повторними спробами в 3 рази скорочує кількість втрачених листів.

Структура таблиці

Мінімальна таблиця для зберігання заявок з форми:

CREATE TABLE form_submissions (
    id          BIGSERIAL PRIMARY KEY,
    form_type   VARCHAR(64) NOT NULL,
    payload     JSONB NOT NULL,
    ip          INET,
    user_agent  TEXT,
    sent_at     TIMESTAMPTZ,
    created_at  TIMESTAMPTZ DEFAULT now()
);

CREATE INDEX idx_form_submissions_form_type ON form_submissions(form_type);
CREATE INDEX idx_form_submissions_created_at ON form_submissions(created_at DESC);

payload у JSONB дозволяє зберігати довільну структуру без міграцій при кожній зміні форми. sent_at — позначка успішної відправки email, NULL означає «ще не відправлено» або «відправка впала».

Серверна обробка (PHP/Laravel)

// app/Http/Controllers/FormController.php
public function submit(Request $request): JsonResponse
{
    $validated = $request->validate([
        'name'    => 'required|string|max:255',
        'email'   => 'required|email|max:255',
        'phone'   => 'nullable|string|max:32',
        'message' => 'required|string|max:4000',
    ]);

    // 1. Зберігаємо в базу одразу — незалежно від пошти
    $submission = FormSubmission::create([
        'form_type'  => 'contact',
        'payload'    => $validated,
        'ip'         => $request->ip(),
        'user_agent' => $request->userAgent(),
    ]);

    // 2. Відправляємо email через чергу
    Mail::to(config('mail.admin_address'))
        ->queue(new FormSubmissionMail($submission));

    return response()->json(['ok' => true]);
}

Ключовий момент: ->queue() замість ->send(). Черга означає, що збій SMTP не поверне 500 користувачеві — заявка вже в базі, лист піде при наступній спробі.

Mailable

// app/Mail/FormSubmissionMail.php
class FormSubmissionMail extends Mailable implements ShouldQueue
{
    use Queueable, SerializesModels;

    public function __construct(public FormSubmission $submission) {}

    public function envelope(): Envelope
    {
        return new Envelope(
            subject: 'Нова заявка: ' . $this->submission->form_type,
            replyTo: [
                new Address($this->submission->payload['email'],
                            $this->submission->payload['name']),
            ],
        );
    }

    public function content(): Content
    {
        return new Content(view: 'emails.form-submission');
    }
}

replyTo заповнюється з даних користувача — менеджер натискає «Відповісти» і лист іде одразу на клієнта, а не на no-reply адресу сайту.

Позначка про успішну відправку

Слухач події MessageSent оновлює поле sent_at:

// app/Listeners/MarkSubmissionSent.php
public function handle(MessageSent $event): void
{
    $message = $event->message;
    // витягуємо submission_id з заголовка X-Submission-Id
    $id = $message->getHeaders()->get('X-Submission-Id')?->getValue();
    if ($id) {
        FormSubmission::where('id', $id)
            ->whereNull('sent_at')
            ->update(['sent_at' => now()]);
    }
}

Заявки з sent_at = NULL можна періодично пересилати через Artisan-команду або переглядати в адміністративній панелі.

Як налаштувати повторну відправку впалих листів?

// app/Console/Commands/RetryUnsentSubmissions.php
// Запускається кожні 15 хвилин через планувальник
$submissions = FormSubmission::whereNull('sent_at')
    ->where('created_at', '<', now()->subMinutes(5))
    ->limit(50)
    ->get();

foreach ($submissions as $submission) {
    Mail::to(config('mail.admin_address'))
        ->queue(new FormSubmissionMail($submission));
}

Ця команда перехоплює заявки, які не відправилися протягом 5 хвилин, і повторює відправку. Ліміт 50 за раз запобігає перевантаженню черги.

Як захистити форму від спаму?

CSRF-токен обов'язковий за замовчуванням у Laravel. Додатково — honeypot-поле та rate limiting (напр., Route::post('/contact', ...)->middleware(['throttle:5,1']) — 5 запитів на хвилину з одного IP). Для високонавантажених форм — reCAPTCHA v3 або Turnstile від Cloudflare (без видимої капчі).

Ми рекомендуємо комбінацію CSRF + honeypot + rate limiting для більшості проєктів. Для високонавантажених форм — Turnstile або reCAPTCHA v3.

Покрокове налаштування

1. Створіть міграцію для таблиці form_submissions.
2. Реалізуйте контролер з валідацією та збереженням.
3. Створіть Mailable клас і шаблон листа.
4. Налаштуйте чергу (Redis або Database) і Supervisor для обробки.
5. Додайте scheduled task для повторної відправки впалих листів.

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

• Підготовка схеми бази даних та індексів під вашу форму
• Розробка контролера з валідацією та збереженням
• Налаштування поштового шаблону та відправки через чергу
• Інтеграція з будь-яким SMTP-провайдером або SES/Mailgun
• Додавання дашборда для перегляду заявок (опціонально)
• Тестування та гарантія безперебійної роботи

Термін реалізації базової версії — 1 робочий день. З дашбордом перегляду заявок і повторною відправкою — 2–3 дні. Вартість рішення розраховується індивідуально під ваш проєкт — від базової версії до розширеної з дашбордом. Економія на запобіганні втратам заявок окупає вкладення в перші ж місяці.

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

Для більш детального вивчення рекомендуємо офіційну документацію: Laravel Mail Documentation.

Послуги бекенд-розробки: 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% без втрати продуктивності.