Интересен ваш опыт и идеи вот по какому вопросу

Господа, как бы вы подошли к решению такой задачи?
Будет проект интернет магазин, где стоимость товара совершенно индивидуальная для каждого посетителя. Пока не буду вас запутывать деталями, пока просто примитивно — цена которую видит покупатель и соответственно может по ней приобрести зависит от того кто этот покупатель, от конкретных скидок на этот товар для этого посетителя, даже от времени суток. Вопрос не в том как это считать, это будет проект состоящих из многих сервисов и расчет скидки ведется сторонним сервисом. Будет отсылаться запрос мол такой-то товар, такой-то клиент и прочая информация и получен ответ о текущей стоимости этого товара для него. Стоимость может изменятся чуть ли не каждые 5 минут, например потому что у сервиса «программа лояльности» есть свой личный кабинет и менеджер, которые там настраивает скидки, бонусы и прочее и может быть настроено вплоть до такого — клиентам у которых в имени есть буква П дать скидку 30% на товары находящиеся на складе номер 4 при условии что покупка будет совершена во время от 15 часов до 18 часов только на бренд такой-то.
Вопрос в том, как правильно и где хранить эти индивидуальные цены. Ведь у сайта планируется не менее 50 000 пользователей и около 2 000 000 товаров. И я вот каюсь, пока не вижу красивого способа, как хранить информацию о цене, если она индивидуальна для каждого покупателя и плюс часто изменяется. Вроде как в базе — нелогично, ну не делать же у таблицы товар 50 000 полей — цена покупателя такого-то, цена покупателя такого-то…
В общем интересны ваши мысли.
И кстати да, речь не о modx и minishop.
Александр Мельник
13 сентября 2020, 09:56
modx.pro
127
0

Комментарии: 4

Юрий
13 сентября 2020, 12:06
0
Добрый день!
Представьте себе цену как некую виртуальную динамическую страницу. Она вроде как есть (при условии совпадения неких входящих данных), на её можно посмотреть и даже она имеет свой адрес, а в реальности её не существует. Здесь в базе хранятся условия, которые её формируют, а не сама цена + некий индификатор совокупности этих условий в виде хеша, например.
В общем, я думаю, идея понятна.
    Александр Мельник
    13 сентября 2020, 13:17
    0
    Спасибо что ответили.
    Нет, честно говоря не совсем понял вашу идею.
    Попробую более подробно описать как будет строиться проект.
    ИМ будет представлять из себя соединитель сторонних сервисов, поскольку у заказчика на данный момент уже по всем миру обычные магазины офлайновые и у них уже заключены договора на обслуживание с множеством различных компаний. Так например данные о товарах в электронном виде хранятся в одной компании, отдельно заключены договора с компанией которая предоставляет услуги «программы лояльности» которая уже ведет учет покупателей, выдачу им бонусных карт, построение сложных акций и так далее. Сейчас это все работает в их офлайн магазинах — данные передаются на кассовые аппараты и когда человек покупает товар, кассовый аппарат получает от сервиса по хранению товаров базовую стоимость товара, потом клиент дает карточку лояльности и по ней идет запрос от кассового аппарата на сервис по работе с лояльностью. Тот сервис проверят что за клиент, сколько у него бонусов, проверяет нет ли для него индивидуальных скидок и возвращает в кассовый аппарат данные — для него товар стоит столько то, если купит получит на бонусный счет столько-то и прочую инфу. Тоесть Цена товара для клиента оказалась индивидуальной и купи этот же товар другой — для него цена была бы другой.
    Эту логику нужно соблюсти и в интернет магазине.
    У нас у товара будет базовая цена, полученная от сервиса по хранению товаров. Она более менее стабильна (обновляется раз в полчаса). А есть цена которую нужно показать конкретному покупателю. Авторизовался человек на сайте, перешел в какой-то раздел с товарами, видит например 50 товаров в списке и у каждого товара уже стоимость конкретно для этого покупателя. И особо проблем тут нет — для начала представим самый простой путь — в момент открытия страницы сайт будет отсылать запросы на сервер который занимается программой лояльности и получать в ответ цену каждого товара — да это трудозатратно но пока представим такой вариант. И на фронтенде ему отрисуется страница с товарами и с его индивидуальными ценами. Но с ценами нужно же работать и на бекенде. Товар он может добавить в корзину, увеличить его количество и прочее и это все должно работать с его индивидуальной ценой. И так у каждого пользователя — к примеру на сайте одновременно 1000 покупателей и каждый должен работать со своей стоимостью товара.
    Ну вот отсюда и мои вопросы и сомнения.
    — если каждый пользователь при каждом открытии страницы будет отсылать по каждому товару запросы на сервер хранящий данные о покупателях, их скидках, то это будет очень высокая нагрузка на их сервер. Возможно это делать заранее, для каждого покупателя пару раз в день получая все цены, но дело в том, что информация меняется очень динамично — к примеру акция может закончиться в 23 часа ночи, а обновление цен запланировано на 3 часа ночи, значит покупатель сделавший заказ в час ночи вызовет сбой в ценах — купит не по той цене.
    — ну и плюс не совсем пока представляю где правильнее хранить такие объемы данных, чтобы они были индивидуальны у каждого пользователя и доступны как для фронтенда так и для бекенда.
    Я конечно придумаю решение, но в мире много умных и опытных людей и их помощь важна.
      Юрий
      13 сентября 2020, 16:16
      0
      Вот я не вижу тут особых проблем. Да и вы сами владеете темой и смогли бы прописать архитектуру и обкатать её как нибудь пилотно.
      На вскидку, есть 3 сущности:
      1. Базовая цена
      2. Бонусы покупателя
      3. Внешние события (акции, скидки и т.п.)
      Они связаны некоей логикой. Данные храняться в трёх местах:
      1. База данных
      2. Кеш
      3. Кеш (клиент)
      Они связаны некоей логикой
      Много покупателей > много денег > хороший программист > мощное железо
      Тонкости организации хранения и обработки это уже другой вопрос.
    Артем
    13 сентября 2020, 15:17
    +1
    Если твой сторонний сервис не предоставляет никаких TTL (время жизни цены) или любой другой информации, по которой можно отследить ее актуальность, то у тебя есть 2 пути:
    — либо ты делаешь запрос каждый раз, когда нужно узнать цену
    — либо ты кэшируешь ее на любое время, которое считаешь нужным.
    В первом случае клиенты твоего сайта получат всегда актуальные цены перед глазами, а во втором — нет, поэтому тебе нужно будет принудительно запрашивать цену перед, например, оформлением заказа, ну и уведомлять клиента о том, если она изменилась за это время.

    Вопрос нагрузки на их сервис — не твоя забота. Если они хотят меньшую нагрузку, то пусть добавляют к ценам TTL, либо предоставляют тебе возможность общаться с их сервисом в рилтайме посредством сокетов.

    Лично мне вариант с сокетами кажется наиболее разумным решением — клиенты всегда видят актуальные цены, не нужно слать по 150 запросов в секунду, все довольны.
      Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
      4