sweetdoughnut, доступ к базе товаров никто вам не даст, если у вас его уже нет. Это, как правило, закрытые складские базы. Создавать это надо самостоятельно или воспользоваться одним из готовых решений
sweetdoughnut, код за вас никто не напишет. Надо выбрать сканер (или собрать, или использовать камеру), выбрать язык, доступный для взаимодействия и написать код. Также надо реализовать api под это все и поместить эти 2 куска в одну сеть (или пустить через интернет)
datkyu, fullstack это не о качестве знаний, а способности вписываться в новый для себя блудняк и его затаскивать. Фуллстаки, практически все, качественных знаний не имеют по тому что им важнее получать ширину чем глубину
Сергей Горностаев, и даже в кэше агрегат не хранится? это же **здец для высоконагруженных систем с высочайшими требованиями к консистенции. А если там не только сложение и вычитание должно использоваться?
Сергей Горностаев, окей, я юр-лицо и на мой счет каждую секунду сыпятся переводы средств. Чтобы посмотреть итог надо что - пойти все транзакции собрать чтобы рассчитать итоговую сумму с последнего снапшота? Пример может и дурацкий, но я его привел как то что может помочь нам сойтись в видении
Сергей Горностаев, у меня сильное подозрение что мы говорим про одно и то же, но не понимаем друг друга. Я про то что по итогу событий каждый раз должна рассчитываться цифра и фиксироваться где-то в базе. Чтобы не перерасчитывать каждый раз при обращении и минимизировать этот участок. Также про то что изменения итога должны быть инкрементыльны и должен храниться лог операций для валидации текущего состояния и поиска ошибок в проде
Сергей Горностаев, ни в коем случае нельзя так поступать. Ошибка в коде может привести к непредсказуемым последствиям. Баланс всегда должен быть зафиксированным результатом пополнений или списаний
Данил Кислов, а вот теперь мы перешли вообще в другую предментую область. Заказ это всегда конечный процесс, который заканчивается. В данном случае это следующий шаг - исполнение услуги. И тут идет подписочная модель (subscriptions).
В таком случае самое логичное - держать базу ближайших событий, отправлять их в очередь на исполнение поминутно, и при вызове каждого в транзакции создавать новое событие и удалять старое
