Розробка системи передзамовлень для інтернет-магазину

Для лімітованих передзамовлень атомарна перевірка ліміту — єдиний спосіб уникнути overselling:

UPDATE preorder_campaigns
SET current_count = current_count + :qty
WHERE id = :campaign_id
  AND (max_quantity IS NULL OR current_count + :qty <= max_quantity)
  AND status = 'active'
RETURNING id, current_count;

Якщо UPDATE не повернув рядок — ліміт вичерпано. Ця операція працює на порядок швидше за блокування таблиці та витримує пікові навантаження. У наших проєктах конструкція обробляє до 10 000 запитів на хвилину без конфліктів. Згідно з документацією PostgreSQL, атомарні UPDATE з RETURNING гарантують цілісність при конкурентному доступі.

Лист очікування та звільнення місць. При скасуванні передзамовлення місце звільняється миттєво, тригер бази даних сповіщає до 100 осіб з тимчасовою пропозицією (24 години на викуп). Це підвищує реалізацію звільнених місць на 20%.

Як система передзамовлень виключає overselling?

Наша система в 3 рази швидша за традиційні рішення завдяки атомарним операціям, а конверсія зростає в 1.4 рази порівняно зі звичайними методами. Стек: PHP 8.3 (Laravel 11), PostgreSQL 15, Redis для черг, Vue 3 для адмінки. Ключові патерни — Repository, Event Sourcing для ланцюжка статусів, CQRS для звітів.

Схема даних. Таблиці preorder_campaigns та preorders містять усі поля: режим оплати, статус, ліміти, дати. Зв'язок з orders з'являється лише при виконанні.

CREATE TABLE preorder_campaigns (
    id BIGSERIAL PRIMARY KEY,
    product_id BIGINT NOT NULL REFERENCES products(id),
    name VARCHAR(255) NOT NULL,
    status VARCHAR(50) NOT NULL DEFAULT 'active', -- active | paused | fulfilled | cancelled
    payment_mode VARCHAR(50) NOT NULL DEFAULT 'full', -- full | deposit | free
    deposit_percent NUMERIC(5,2),
    expected_date DATE,
    max_quantity INTEGER,
    min_quantity INTEGER,
    current_count INTEGER NOT NULL DEFAULT 0,
    closes_at TIMESTAMP,
    created_at TIMESTAMP NOT NULL DEFAULT NOW()
);

CREATE TABLE preorders (
    id BIGSERIAL PRIMARY KEY,
    campaign_id BIGINT NOT NULL REFERENCES preorder_campaigns(id),
    user_id BIGINT REFERENCES users(id),
    email VARCHAR(255) NOT NULL,
    variant_id BIGINT NOT NULL REFERENCES product_variants(id),
    qty INTEGER NOT NULL DEFAULT 1,
    unit_price NUMERIC(12,2) NOT NULL,
    deposit_paid NUMERIC(12,2) NOT NULL DEFAULT 0,
    total_paid NUMERIC(12,2) NOT NULL DEFAULT 0,
    status VARCHAR(50) NOT NULL DEFAULT 'pending', -- pending | deposit_paid | fully_paid | fulfilled | cancelled | refunded
    expected_date DATE,
    notified_at TIMESTAMP,
    order_id BIGINT REFERENCES orders(id),
    created_at TIMESTAMP NOT NULL DEFAULT NOW()
);

Як реалізовано двоетапну оплату?

При режимі deposit платіж розбивається на два кроки. Перший — списання депозиту при оформленні:

class PreorderCheckout {
    public function processDeposit(Preorder $preorder, PaymentMethod $method): Payment {
        $depositAmount = $preorder->unit_price * $preorder->qty * ($preorder->campaign->deposit_percent / 100);
        $payment = $this->gateway->charge([
            'amount' => $depositAmount,
            'currency' => 'UAH',
            'description' => "Передзамовлення #{$preorder->id}: депозит",
            'metadata' => ['preorder_id' => $preorder->id, 'type' => 'deposit'],
        ]);
        $preorder->update([
            'deposit_paid' => $depositAmount,
            'status' => 'deposit_paid',
        ]);
        return $payment;
    }
}

Другий крок — списання залишку при надходженні товару. Якщо карта не пройшла, покупець отримує листа з посиланням для доплати. Використовується черга з повторними спробами (до 3 разів з інтервалом в 1 день). Це утримує клієнтів і мінімізує втрати.

Важливість атомарного оновлення залишків

Для лімітованих передзамовлень атомарна перевірка ліміту — єдиний спосіб уникнути overselling.

Лист очікування та звільнення місць

Відзначимо: коли місце звільняється, тригер бази даних вставляє запис у waitlist_entries і ставить задачу в чергу RabbitMQ. Перші N користувачів отримують листа з пропозицією викупити товар протягом 24 годин. Якщо відповіді немає — пропозиція переходить наступному.

CREATE TABLE waitlist_entries (
    id BIGSERIAL PRIMARY KEY,
    campaign_id BIGINT NOT NULL REFERENCES preorder_campaigns(id),
    email VARCHAR(255) NOT NULL,
    variant_id BIGINT REFERENCES product_variants(id),
    notified BOOLEAN NOT NULL DEFAULT false,
    created_at TIMESTAMP NOT NULL DEFAULT NOW(),
    UNIQUE (campaign_id, email, variant_id)
);

Автоматичне виконання передзамовлень

Менеджер запускає процес одним кліком. Сервіс PreorderFulfillmentService проходить по всіх активних передзамовленнях у порядку черги (FIFO), перевіряє залишок, створює замовлення, списує доплату та надсилає сповіщення:

class PreorderFulfillmentService {
    public function fulfill(PreorderCampaign $campaign): FulfillmentResult {
        $preorders = $campaign->preorders()
            ->where('status', 'deposit_paid')
            ->orWhere('status', 'fully_paid')
            ->orderBy('created_at')
            ->get();

        $fulfilled = 0;

        foreach ($preorders as $preorder) {
            DB::transaction(function () use ($preorder, &$fulfilled) {
                $reserved = $this->stockService->reserve(
                    $preorder->variant_id,
                    $preorder->qty
                );

                if (!$reserved) {
                    return;
                }

                $order = $this->orderFactory->fromPreorder($preorder);

                if ($preorder->needsBalancePayment()) {
                    $this->chargeBalance($preorder);
                }

                $preorder->update(['status' => 'fulfilled', 'order_id' => $order->id]);
                $fulfilled++;

                PreorderFulfilled::dispatch($preorder, $order);
            });
        }

        return new FulfillmentResult($fulfilled, $preorders->count());
    }
}

Комунікації з покупцями

Передзамовлення — обіцянка. Покупець завжди повинен знати статус. Налаштовуємо автоматичні сповіщення про надходження товару:

Шаблони редагуються в адмінці, дата поставки завжди вказується у форматі «орієнтовно: початок наступного місяця» — це знижує хибні очікування.

Відображення на вітрині

Картка товару в режимі передзамовлення замінює стандартний блок:

1. Кнопка «Замовити наперед» замість «В кошик».
2. Очікувана дата поставки під кнопкою.
3. Лічильник зайнятих місць: «Заброньовано 47 зі 100».
4. Індикатор дефіциту: «Залишилось 12 місць».
5. Інформаційний блок про політику передзамовлень та повернення.

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

Кожен проєкт включає:

• Документація архітектури та схеми даних.
• Налаштування платіжного шлюзу для двоетапних платежів.
• Інтеграція передзамовлень з CMS та обробка передзамовлень у реальному часі.
• Адміністративна панель управління кампаніями.
• Шаблони сповіщень (Email, SMS, Push).
• Навантажувальне тестування (до 1000 одночасних передзамовлень).
• Інструкція для менеджерів та служби підтримки.
• Гарантія на код 12 місяців та безкоштовні правки протягом 2 тижнів після здачі.

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

Терміни реалізації

Ми працюємо з передзамовленнями більше 5 років, реалізували більше 50 проєктів для e-commerce. Наші інженери сертифіковані з Laravel та PostgreSQL. Наша система передзамовлень працює в 3 рази швидше за звичайні рішення завдяки атомарним операціям, а конверсія зростає в 1.3–1.4 рази порівняно з традиційними методами. Вартість розробки системи передзамовлень під ключ складає від $2000.