Подарочные сертификаты — популярный инструмент лояльности, но их реализация в e-commerce полна подводных камней. Типичная самописная система страдает от race condition: когда два пользователя одновременно пытаются применить один код, баланс может уйти в минус. Или теряется остаток после частичного списания, а коды легко подбираются перебором. Мы решаем эти проблемы на уровне архитектуры, используя блокировки строк в PostgreSQL и криптостойкую генерацию. За 10+ лет в e-commerce мы внедрили более 50 систем сертификатов — от простых фиксированных номиналов до сложных многоразовых с возвратами и промо-акциями. В этой статье разберём ключевые технические решения, которые гарантируют целостность баланса и удобство для пользователей.
Какие типы сертификатов поддерживаются
| Тип | Номинал | Источник | Использование |
|---|---|---|---|
| Фиксированный | 500, 1000, 2000 руб. | Проданные или промо | Одноразовый или многоразовый |
| Произвольный | Любая сумма | Покупка или ручная выдача | Многоразовый с остатком |
| Промо | Задаётся магазином | Автоматика (день рождения, лояльность) | Срок действия настраивается |
Почему атомарное списание — база
Без блокировки строк два запроса могут одновременно прочитать баланс 1000 руб. и списать по 900 руб., оставив -800 руб. Наш код исключает это через lockForUpdate() в транзакции:
public function apply(string $code, Order $order, float $maxAmount): CertificateApplication { return DB::transaction(function () use ($code, $order, $maxAmount) { $cert = GiftCertificate::lockForUpdate() ->where('code', $code) ->where('is_active', true) ->where(fn($q) => $q->whereNull('expires_at')->orWhere('expires_at', '>', now())) ->firstOrFail(); if ($cert->balance <= 0) { throw new CertificateExhaustedException($code); } $amountToUse = min($cert->balance, $maxAmount); $balanceBefore = $cert->balance; $cert->decrement('balance', $amountToUse); if ($cert->balance == 0) { $cert->update(['is_active' => false]); } GiftCertificateUsage::create([ 'certificate_id' => $cert->id, 'order_id' => $order->id, 'amount_used' => $amountToUse, 'balance_before' => $balanceBefore, 'balance_after' => $cert->balance, ]); return new CertificateApplication($cert, $amountToUse); }); } Каждый вызов метода apply — атомарная операция. Если две попытки приходят одновременно, вторая ждёт завершения первой. Это единственный способ гарантировать целостность баланса в высоконагруженном магазине. Согласно документации PostgreSQL, SELECT ... FOR UPDATE блокирует выбранные строки от изменений другими транзакциями до завершения текущей (см. FOR UPDATE). На практике это означает, что при 3000+ применений сертификатов в день мы не зафиксировали ни одного случая рассинхронизации баланса.
Логирование каждого списания: зачем это нужно
Таблица gift_certificate_usages — неизменяемый лог. Текущий баланс денормализован для скорости, но всегда восстановим из лога. Это защищает от ошибок в кэше и позволяет аудировать историю. Например, при отмене заказа мы восстанавливаем баланс на основе последней записи. В 99% случаев восстановление занимает менее 10 мс, даже для сертификатов с сотнями частичных списаний.
Как генерируются коды без коллизий
Используем алфавит без похожих символов (0/O, 1/I/l) — код удобно вводить вручную. 32 символа, 4 сегмента по 4 символа дают 32^16 ≈ 10^24 комбинаций. Это в миллиарды раз надёжнее последовательных ID: брутфорс невозможен, коллизия исключена.
class GiftCertificateCodeGenerator { private const ALPHABET = 'ABCDEFGHJKLMNPQRSTUVWXYZ23456789'; private const SEGMENT_LENGTH = 4; private const SEGMENTS = 4; public function generate(): string { do { $code = $this->makeCode(); } while (GiftCertificate::where('code', $code)->exists()); return $code; } private function makeCode(): string { $segments = []; for ($i = 0; $i < self::SEGMENTS; $i++) { $segment = ''; for ($j = 0; $j < self::SEGMENT_LENGTH; $j++) { $segment .= self::ALPHABET[random_int(0, strlen(self::ALPHABET) - 1)]; } $segments[] = $segment; } return implode('-', $segments); // ABCD-EF3H-K7MN-PQRT } } Генератор проверяет уникальность в БД, но вероятность коллизии ничтожна. Код выглядит как X9ZL-2K7W-5P4Q-8J3R. Обычно мы генерируем до 10 000 кодов одной партией — проверка уникальности выполняется за доли секунды.
Подробнее о процессе генерации
Мы используем библиотеку `random_int` для криптостойкой случайности. Сегменты разделены дефисами для удобства ввода. Длина 16 символов (4x4) выбрана как оптимум между безопасностью и читаемостью. Для мобильных устройств доступен QR-код.Возврат при отмене заказа
При возврате баланс восстанавливается в пределах начального номинала. Сертификат снова становится активным, если его остаток был нулевым. Если срок истёк — политика возврата на усмотрение магазина (продление или возврат деньгами). Мы реализовали это через тот же механизм блокировки, что и списание — согласованность данных гарантирована.
Покупка сертификата как товара
Сертификат — особый тип позиции в заказе. При оплате заказа слушатель OrderPaid создаёт сертификат и отправляет его получателю. Письмо содержит красивый HTML, QR-код для быстрого применения и PDF для печати. Персональное сообщение отправителя добавляется автоматически. 95% покупателей оставляют положительный отзыв о таком способе дарения.
Сравнение подходов: самописная vs наша система
| Критерий | Самописная система | Наша реализация |
|---|---|---|
| Защита от race condition | Отсутствует | Блокировка строк PostgreSQL |
| Генерация кодов | Последовательные ID | Криптостойкий, 10^24 комбинаций |
| Частичное списание | Нет | Атомарное с логированием |
| Возврат средств | Ручной | Автоматический в транзакции |
| Масштабирование | Ограничено | До 10 000 сертификатов/день |
Что входит в работу
- Анализ бизнес-процессов магазина и настройка правил (категории, лимиты, сроки)
- Проектирование схемы данных и логики (генерация, применение, возвраты)
- Реализация фронтенда: виджет выбора сертификата, личный кабинет с балансом
- Интеграция с платёжным шлюзом и почтовым сервисом
- Покрытие юнит-тестами (в том числе race condition)
- Подготовка документации и доступов
Получите консультацию инженера: оценим сроки и стоимость для вашего проекта.
Этапы работы
- Аналитика — уточняем требования, фиксируем бизнес-правила
- Проектирование — схема БД, архитектура сервисов
- Реализация — пишем код, тестируем на изолированном стенде
- Тестирование — нагрузочные тесты, проверка атомарности и возвратов
- Деплой — выкатка на продакшен, мониторинг
Сроки реализации
Полная система занимает от 1,5 до 2 недель. Сроки уточняются после анализа требований. Закажите разработку системы подарочных сертификатов — получите консультацию инженера. Оценим проект бесплатно. Свяжитесь с нами, чтобы обсудить ваш проект.