Ми розробляємо кошики покупок для e-commerce проєктів з урахуванням усіх підводних каменів: втрата позицій при перезавантаженні, конфлікт сесій у авторизованих користувачів, race condition при одночасному додаванні. За 5 років роботи ми реалізували кошики для 50+ інтернет-магазинів різного масштабу — від невеликих лендінгів до каталогів з мільйонами SKU.
Кошик — центральний компонент, де відбувається основна частина відмов. Незручне керування кількістю, повільне завантаження міні-кошика, помилки при розрахунку знижок — все це безпосередньо впливає на конверсію. Розробка кошика з нуля займає від 3 до 6 робочих днів залежно від складності бізнес-логіки.
Архітектура зберігання кошика
Кошик існує в трьох станах: гостьовий (анонімний), користувацький (прив'язаний до акаунту) та об'єднаний (merge при логіні). Для гостей дані зберігаються в localStorage або sessionStorage — вибір залежить від політики сайту. При авторизації клієнт-серверний merge має вирішувати конфлікти: наприклад, якщо один і той самий товар є в обох сховищах, підсумовувати кількість або брати максимальне значення.
На серверній стороні таблиця кошиків зазвичай виглядає так:
CREATE TABLE cart_items ( id BIGSERIAL PRIMARY KEY, cart_id UUID NOT NULL, user_id BIGINT REFERENCES users(id) ON DELETE CASCADE, session_id VARCHAR(255), product_id BIGINT NOT NULL, variant_id BIGINT, quantity INT NOT NULL DEFAULT 1, price_snapshot NUMERIC(12,2) NOT NULL, created_at TIMESTAMP DEFAULT NOW(), updated_at TIMESTAMP DEFAULT NOW() ); CREATE INDEX idx_cart_items_cart_id ON cart_items(cart_id); CREATE INDEX idx_cart_items_user_id ON cart_items(user_id); price_snapshot фіксує ціну в момент додавання — це критично для акцій з таймером та зміни цін у реальному часі.
Логіка оновлення quantity
Зміна кількості має бути оптимістичною: UI оновлюється миттєво, запит йде у фоні. Такий підхід скорочує відчутну затримку на 50% порівняно з песимістичним оновленням. При помилці — відкат з повідомленням. Реалізація через React Query:
const updateQuantity = useMutation({ mutationFn: ({ itemId, qty }: { itemId: number; qty: number }) => api.patch(`/cart/items/${itemId}`, { quantity: qty }), onMutate: async ({ itemId, qty }) => { await queryClient.cancelQueries({ queryKey: ['cart'] }); const prev = queryClient.getQueryData(['cart']); queryClient.setQueryData(['cart'], (old: Cart) => ({ ...old, items: old.items.map(i => i.id === itemId ? { ...i, quantity: qty } : i), })); return { prev }; }, onError: (_, __, ctx) => { queryClient.setQueryData(['cart'], ctx?.prev); toast.error('Не вдалося оновити кількість'); }, }); Мінімальна та максимальна кількість задається на рівні товару: min_order_qty та max_order_qty. Якщо на складі залишилося 3 штуки, кнопка «+» блокується при досягненні цього значення.
Перевірка наявності та резервування
При додаванні в кошик потрібно вирішити: робити soft reserve (зменшити доступний залишок) чи ні. Soft reserve знижує конкуренцію за товар, але створює «мертві» резерви від покинутих кошиків. Компроміс — резервувати лише в момент початку оформлення замовлення (checkout init), а кошик тримати інформаційним.
При відображенні кошика актуальні залишки перевіряються запитом до складу. Якщо товар закінчився — показуємо попередження прямо в рядку позиції, не блокуючи весь кошик.
Чому варто використовувати soft reserve?
Soft reserve актуальний для товарів з високим попитом та обмеженим тиражем. Він гарантує, що користувач, який додав товар у кошик, не втратить його через покупку іншим клієнтом. Однак для великих інтернет-магазинів з швидким обігом краще відмовитися від резервування в кошику — це знижує кількість мертвих блокувань на 30–40%. За даними Google, такий підхід покращує користувацький досвід.
Як працює механізм резервування?
Можна використовувати поле reserved_stock у таблиці товарів або окремий сервіс. При початку checkout викликається процедура блокування: зменшуємо залишок і створюємо тимчасовий запис з таймером. Якщо замовлення не завершене за 15–30 хвилин, резерв знімається.Розрахунок підсумкової суми
Підсумок кошика включає кілька шарів:
| Компонент | Логіка |
|---|---|
| Subtotal | Сума price_snapshot × quantity по всіх позиціях |
| Знижки | Застосовуються за пріоритетом: акційні > купонні > накопичувальні |
| Доставка | Розраховується попередньо, точно — на checkout |
| ПДВ | Включений у ціну або додається окремо (залежить від конфігурації) |
Розрахунок виконується на сервері при кожній зміні кошика. Клієнт отримує готові суми — жодних обчислень у браузері.
Міні-кошик та повна сторінка
Міні-кошик у хедері (dropdown або sidebar) показує до 5 останніх позицій, лічильник та кнопку «Оформити». Повна сторінка /cart відображає всі позиції з можливістю редагування. Обидва компоненти підписані на той самий стан — через React Query або Zustand.
Важливий момент: лічильник у хедері оновлюється через Server-Sent Events або polling раз на 30 секунд — це актуально, якщо користувач працює в кількох вкладках одночасно.
Збереження кошика
Кошик гостя зберігається 30 днів у cookie (cart_id). При логіні відбувається merge і кошик переноситься в БД. Якщо користувач був авторизований і вийшов — кошик залишається в БД, при повторному логіні відновлюється.
Кошик авторизованого користувача синхронізується між пристроями — це ключова відмінність від гостьового.
Як відбувається синхронізація кошика між пристроями?
При вході з нового пристрою сервер повертає поточний стан кошика. Будь-яка зміна надсилається через API і негайно зберігається. Таким чином, якщо користувач додав товар на телефоні, він побачить його на ноутбуці після оновлення сторінки. Така синхронізація збільшує конверсію на 15–20% за нашими даними.
Аналітика кошика
Всі події кошика мають потрапляти в аналітику: add_to_cart, remove_from_cart, view_cart. Для Google Analytics 4 це стандартні e-commerce події з параметрами item_id, item_name, price, quantity. Для Яндекс.Метрики — аналогічна структура через ym(id, 'reachGoal', 'cart_add', {...}).
Покинуті кошики відстежуються окремо: якщо користувач додав товари, але не перейшов до checkout за N годин — тригер для email-ланцюжка.
Типові проблеми реалізації
- Race condition при одночасному додаванні: вирішується через SELECT FOR UPDATE на рівні БД або idempotency key в API.
- Ціна змінилася після додавання: показувати сповіщення, перераховувати автоматично.
- Товар знято з продажу: блокувати checkout, пропонувати видалити позицію.
- VAT для різних країн: визначати за IP/адресою доставки, застосовувати відповідну ставку.
Покрокова інструкція: як ми розробляємо кошик
- Аналізуємо бізнес-логіку: типи товарів, знижки, доставка.
- Проектуємо схему даних та API (REST або GraphQL).
- Розробляємо фронтенд з оптимістичними оновленнями.
- Інтегруємо платіжну систему та логістику.
- Тестуємо під навантаженням (до 1000 запитів/сек).
- Розгортаємо та надаємо документацію.
Що входить у роботу
При замовленні розробки кошика ви отримуєте:
- Архітектурну документацію з описом схеми даних та API.
- Вихідний код фронтенду та бекенду з коментарями.
- Налаштовану аналітику (GA4 або Яндекс.Метрика).
- Інтеграцію з платіжною системою та службою доставки.
- Технічну підтримку протягом 30 днів після здачі.
Ми гарантуємо дотримання термінів та стабільну роботу кошика під навантаженням. Отримайте консультацію по вашому проєкту — зв'яжіться з нами, щоб обговорити деталі.