это будет часто обновляемый count в виде quantity у каждого товара\партии товара, но тогда велком уровни изоляции транзакции(возможно медленная работа либо грязное чтение)
Второй вариант event sourcing, когда все операции будем складывать, но как корректно и без огромных затрат по базе калькулировать это? Да можно положить в редис, но при каких-то крайних кейсах, словно можно потерять достоверность данных
У нас сначала была запись номенклатуру с quantity как раз, потом пришли к тому что каждая единица должна быть отдельна, да работа с обновлениями дольше, но зато удобнее потом при такой архитектуре работать с другими сущностями
каждая отдельная единица товара отдельной записью? Ощущение что в перфомансе можно потерять
сага убавления, прибавления к партии товара. таким образом последния запись будет итоговое количество товара
Ага, как если бы работали с настоящей физическим объектом, тогда и резерв и пр. операции проходят без проблем
а при параллельных запросах, оно одинаковые товары не отберёт 🤔
а как считаете количество ? если товаров больше миллиона например :)
Ну миллиона нет, но тысячи бывают)
если это один магазин, куда не шло, когда у тебя SAAS
Каунтер + запись всех операций с товаром (при необходимости запускается пересчёт) + физическая инвентаризация
или, сага, и не будет путаницы с счётчиками, иначе когда ты поймёшь что нужен пересчет ?
Отдельная сущность с айдишкой товара и номером штрих кода етц
зато какое логирование можно залабать прям как в банке
Обсуждают сегодня