Каталог, корзина и оформление заказа

01Каталог: товары, варианты и атрибуты

Представьте товар как ценник на полке («Лак для ногтей»), а вариант — как конкретную вещь, которую кладут в коробку («Лак для ногтей, красный, 15 ml»). Покупатели просматривают товары, но продаёте, храните на складе и оцениваете вы именно варианты — у каждого варианта свой SKU (stock-keeping unit, уникальный артикул), цена и остаток. Атрибуты описывают варианты: цвет, размер, вес, вкус. Если сгруппировать атрибуты в семейства («одежда» — размер и цвет, «корм для животных» — вес и вкус), админка останется вменяемой. Категории образуют дерево (Собаки → Корм → Сухой корм); храните его как nested set или как parent_id плюс закэшированный путь, чтобы «все товары в разделе Собаки» получались одним запросом. Бренды, теги и подборки — это отдельные связи many-to-many, а не дополнительные категории.

• Товар: название, описание, изображения, SEO-поля, связи с категориями.
• Вариант: SKU, значения атрибутов, цена, вес, штрихкод, связь с остатками.
• Некоторые товары продаются упаковками или на вес — моделируйте единицу продажи явно, а не через хаки с количеством.

02Деньги: целые числа, валюты и налоги

Никогда не храните деньги во float. В двоичной арифметике с плавающей точкой 0.1 + 0.2 не равно 0.3, и эти крошечные ошибки складываются в реальные расхождения в бухгалтерии. Храните суммы как целые числа в минимальных единицах (центы или целые драмы для валют без дробных единиц) вместе с кодом валюты по ISO 4217, а вычисления делайте через библиотеку для денег или value object. Один раз решите, включают ли цены в каталоге налог (обычно так в потребительских магазинах Европы, Армении и Австралии) или нет (обычно так в США), и считайте налог по каждой строке с понятным правилом округления. Сохраняйте снимок каждой цены, скидки и налога в строке заказа: каталог завтра изменится, а заказ всё равно должен показывать то, что заплатил покупатель.

1// Money as a small value object: integer minor units + currency
2type Money = { amount: number; currency: "USD" | "EUR" | "AMD" };
3 
4const add = (a: Money, b: Money): Money => {
5  if (a.currency !== b.currency) throw new Error("Currency mismatch");
6  return { amount: a.amount + b.amount, currency: a.currency };
7};
8 
9// Tax included in the price: extract it with one explicit rounding rule
10const taxIncluded = (gross: Money, ratePercent: number): Money => ({
11  amount: Math.round((gross.amount * ratePercent) / (100 + ratePercent)),
12  currency: gross.currency,
13});
14 
15const line = { amount: 1999, currency: "USD" } as const; // $19.99
16console.log(taxIncluded(line, 20)); // { amount: 333, currency: "USD" }

03Корзина: гости, слияние и валидация

Позвольте людям делать покупки без аккаунта. Гостевая корзина живёт на сервере и идентифицируется случайным токеном, который хранится в cookie (веб) или в защищённом хранилище (приложение). Если корзина на сервере, цены и правила считаются в одном месте, а после входа корзина следует за пользователем на всех устройствах. Когда гость входит в аккаунт, выполните слияние: добавьте гостевые строки в корзину аккаунта, объедините количества для одного и того же варианта, затем удалите гостевую корзину. Относитесь к корзине как к пожеланию, а не к обещанию. Каждый раз при чтении — и обязательно при оформлении заказа — перепроверяйте её: активен ли ещё вариант, хватает ли остатка, не изменилась ли цена, открыт ли филиал, набрана ли минимальная сумма заказа? Возвращайте понятные сообщения («Цена изменилась с 12.00 на 13.50»), а не исправляйте всё молча.

• Храните в корзине ID вариантов и количества, а не цены, присланные клиентом.
• Пересчитывайте итоги на сервере в каждом ответе.
• Предложите повтор заказа: скопируйте строки из прошлого заказа в корзину, а затем проверьте их как обычно.

04Оформление заказа и машина состояний

Checkout собирает всё, что нужно заказу, — контакты, адрес или пункт самовывоза, время доставки, способ оплаты — и затем создаёт заказ в одной транзакции базы данных: копирует строки корзины со снимками цен, резервирует остатки, сохраняет итоги и ставит статус «ожидает оплаты». С этого момента заказ движется по явной машине состояний. Машина состояний — это просто список допустимых статусов и допустимых переходов между ними. Если записать её явно, не случится абсурда вроде отменённого заказа, который вдруг стал доставленным, а каждый переход логируется в таблицу истории статусов с указанием, кто и когда его сделал. Побочные эффекты — письма, push-уведомления, экраны на кухне, экспорт в ERP — вешаются на переходы, в идеале через задачи в очереди.

1const transitions = {
2  pending_payment: ["paid", "cancelled"],
3  paid: ["preparing", "refunded"],
4  preparing: ["ready", "cancelled"],
5  ready: ["out_for_delivery", "picked_up"],
6  out_for_delivery: ["delivered", "failed_delivery"],
7  delivered: ["refunded"],
8} as const;
9 
10type Status = keyof typeof transitions | "cancelled" | "refunded" | "picked_up" | "failed_delivery";
11 
12export function canMove(from: Status, to: Status): boolean {
13  const allowed = (transitions as Record<string, readonly string[]>)[from] ?? [];
14  return allowed.includes(to);
15}

05Доставка, самовывоз и временные слоты

Исполнение заказа — это то, чем магазины отличаются сильнее всего. Для доставки нужны адрес, зона и стоимость. Зоны обычно задаются полигонами на карте: геокодируйте адрес в координаты, затем проверьте, какой полигон содержит эту точку, — так вы получите стоимость доставки, минимальную сумму заказа и обслуживающий филиал. Для самовывоза (takeaway) нужен филиал и, возможно, список товаров, который отличается от филиала к филиалу. Временные слоты превращают часы работы в окна, которые можно выбрать: «как можно скорее» или на определённое время с шагом 15 или 30 минут, с учётом времени приготовления, времени закрытия и «рабочего дня», который может заканчиваться после полуночи. Генерируйте слоты на сервере, в часовом поясе магазина, и перепроверяйте выбранный слот при оформлении — слот, свободный при загрузке страницы, через минуту может оказаться занят.

06Защита от перепродажи и правильные письма

Перепродажа (overselling) случается, когда два покупателя одновременно покупают последний товар. Решение — сделать изменение остатка атомарным. Либо заблокируйте строку (SELECT … FOR UPDATE внутри транзакции), либо используйте условное обновление, которое срабатывает только при достаточном остатке, и проверяйте количество затронутых строк. Резервируйте остаток при создании заказа и освобождайте его, если оплата не прошла или истекло время; задача по расписанию отменяет брошенные заказы в статусе ожидания. Транзакционные письма — заказ получен, оплачен, отправлен, возвращён — нужно отправлять из очереди после коммита транзакции, чтобы медленный почтовый сервер никогда не блокировал checkout и чтобы не ушло письмо о заказе, транзакция которого откатилась.

1-- Atomic decrement: succeeds only when enough stock is left
2UPDATE stock_levels
3SET quantity = quantity - 2
4WHERE variant_id = 42
5  AND warehouse_id = 1
6  AND quantity >= 2;
7-- 1 row affected → reserved; 0 rows → out of stock, tell the customer

07Идемпотентное создание заказа: как пережить двойные клики и повторы

Покупатель дважды нажимает «Оформить заказ», мобильное приложение повторяет запрос после таймаута, балансировщик нагрузки переотправляет запрос. Без защиты каждый такой случай может создать второй заказ и дважды зарезервировать остаток. Решение — checkout key: клиент генерирует случайный UUID при открытии экрана оформления и отправляет его вместе с запросом. Сервер сохраняет его в заказе под уникальным ограничением. Первый запрос создаёт заказ; любой повтор с тем же ключом возвращает уже существующий заказ вместо создания нового. Храните ключ на протяжении всей попытки оформления и генерируйте новый только при изменении корзины. Дополните это короткой блокировкой на корзину (Redis lock или advisory lock), чтобы два параллельных запроса не прошли валидацию раньше, чем один из них сделает вставку.

1-- One order per checkout attempt, enforced by the database
2ALTER TABLE orders ADD COLUMN checkout_key UUID;
3CREATE UNIQUE INDEX orders_checkout_key_uq ON orders (checkout_key);
4 
5-- Inside the checkout transaction
6INSERT INTO orders (checkout_key, customer_id, status, total_amount, currency)
7VALUES ($1, $2, 'pending_payment', $3, $4)
8ON CONFLICT (checkout_key) DO NOTHING
9RETURNING id;
10-- No row returned → a previous request already created it:
11-- SELECT id FROM orders WHERE checkout_key = $1 and return that order.

08Распределение скидок и округление без потери копейки

Скидку на всю корзину («5.00 с заказа») нужно разложить по строкам, потому что налоги, возвраты и выгрузки в ERP работают построчно. Делите её пропорционально стоимости каждой строки, округляйте каждую долю вниз, а оставшиеся центы отдайте строкам с наибольшими остатками. Доли всегда в сумме дают точную скидку, а последующий частичный возврат одной строки вернёт ровно то, что за неё списали. Также учитывайте минимальную единицу валюты из ISO 4217: у большинства валют 2 знака после запятой, у японской иены 0, а у кувейтского динара 3. Никогда не хардкодьте «делим на 100». В мультивалютных магазинах сохраняйте курс обмена в заказе и решите, конвертируете ли вы только цены (валюта отображения) или реально списываете деньги в этой валюте (валюта расчётов).

1// Split an integer amount across weights; parts always sum to the total
2export function allocate(total: number, weights: number[]): number[] {
3  const sum = weights.reduce((a, b) => a + b, 0);
4  const raw = weights.map((w) => (total * w) / sum);
5  const parts = raw.map(Math.floor);
6  let rest = total - parts.reduce((a, b) => a + b, 0);
7  const order = raw
8    .map((r, i) => ({ i, frac: r - Math.floor(r) }))
9    .sort((a, b) => b.frac - a.frac);
10  for (const { i } of order) {
11    if (rest-- <= 0) break;
12    parts[i] += 1;
13  }
14  return parts;
15}
16 
17allocate(500, [1999, 999, 2]); // [333, 167, 0] → sums to 500

09Read models для быстрых страниц каталога

Страница категории, которая на каждый запрос джойнит товары, варианты, цены, остатки, изображения и акции, с ростом каталога становится медленной. Обычный ответ — read model: денормализованная таблица (или документ поискового индекса) с одной строкой на товар, где лежит ровно то, что нужно листингу, — минимальная цена, флаг наличия, главное изображение, значения атрибутов для фильтров, рейтинг. Фоновые задачи обновляют её при изменении исходных данных, а витрина читает только эту таблицу. Кэшируйте отрендеренные фрагменты или ответы API с тегами, чтобы изменение цены инвалидировало только затронутые товары. Write model (нормализованные таблицы, транзакции) остаётся источником истины; read model всегда можно перестроить из неё. Такое разделение, которое иногда называют CQRS (command query responsibility segregation), позволяет масштабировать чтение, не усложняя оформление заказа.

• Перестраивайте read-строку товара в задаче из очереди после изменения цены, остатка или контента.
• Для глубоких страниц используйте keyset-пагинацию (WHERE id > last_id).
• Никогда не вычисляйте живые цены по акциям для каждого товара в листинге; заранее рассчитывайте бейджи.

10Граничные случаи безопасности в корзинах и заказах

Корзины и заказы — классическая цель для insecure direct object references (IDOR): меняешь /orders/1042 на /orders/1043 и видишь чужой заказ. Используйте в URL неугадываемые публичные идентификаторы (UUID или случайные токены) и всегда ограничивайте запросы владельцем. Меняйте токен гостевой корзины при входе пользователя, чтобы токен, перехваченный до входа, нельзя было использовать для чтения корзины аккаунта. Валидируйте количество как положительное целое с верхним пределом — отрицательные количества в плохо сделанных магазинах приводили к реальным возвратам денег. Ставьте rate limit на эндпоинты купонов и оформления заказа, чтобы замедлить перебор и card testing, когда злоумышленники прогоняют украденные карты через мелкие заказы. И наконец, храните в заказах минимум персональных данных и продумайте срок их хранения, потому что таблицы заказов незаметно становятся вашим самым большим хранилищем персональных данных.