Накопление знаний
Математическо-низкоуровневое

Обновить цены на сайте

На;самом деле путь «гиковский» пока существует только в виде прототипа, но всё же...

В очередной раз мне поступила задача на;проектирование из разряда «миллион номенклатур» ежедневный робот изменения цены на сайте.

Как обычно данная задача решается наиболее стабильно через RabbitMQ или/и Kafka— то есть введением событийности между 1С и сайтом на PHP.

То есть в момент «изменения цены» мы отправляет с событие в «точку обмена"/"тему» (терминология AMQP/Kafka) — здесь всё просто и миллион раз уже проделывалось. Так как клиент оплатил именно проработку архитектурного решения, которое уже есть — то появилось время еще раз продумать и выдумать что-то «исследовательское» и непонятное.

И тут вопрос, А зачем нам цены на сайте ?

На самом деле— основная причина почему мы именно выгружаем цены на сайт, потому что задачу формируют ИТ специалисты которые ответственны за сайт — а у них там есть табличка Price/Goodsprice/PriceLists откуда они потом делают SELECT и уже показывают на сайте. Возможно даже они управляют кешерованием через Redis/memcached.

Но ведь бизнес-задача обычно звучит другим образом. Мы хотим торговать на сайте товаром по ценам. А кто давно в ритейле - тот знает - мы хотим не выгрузить цены, а применить ценники.

В физическом ритейле - у нас даже есть такая процедура - печать ценников, которая означает "регламентное введение в действие цены", самое прикольно что закон о защите прав потребителей еще и обязует ритейлера "продать по той цене которую увидел клиент".

Таким образом задача то на самом деле звучит как:

Нужно на сайте обновлять ценники на товар, а ценообразованием стоит управлять на стороне решения класса ERP

То есть нужно разделять жизненный цикл ценообразования:

  • обновление ценников
  • формирование цены для ценника
  • персональные скидки

В этом случае именно на обновление ценников у нас подписывается клиентская часть - а для этого у нас есть WebSocket, причем применительно к RabbitMQ - мы в можем схитрить и открыть порт WebStomp для клиента, если серверные программисты не имеют WebSocket

Гиковость такого решения и так понятна - на сервере необходимо обработать 4 события

  • клиент пришел первый раз - какой ценник ему показать, соответственно сервер требуется подписать на поток из Apache Kafka - чтобы можно было держать актуальные цены на сайте из 1С из конкретного топика. Придется в том числе решить - насколько долго хранить журнал транзакций изменения цены на стороне Apache Kafka
  • клиент пришел со старым ценником - зафиксировать цену продажи и отличие от текущей цены по которой мы торгуем всем, для последующего анализа.
  • клиент пришел с новым ценником - а мы еще не успели загрузить новые цены из журнала транзакций - зафиксировать цену продажи и отличие от текущей цены по которой мы торгуем всем, для последующего анализа.
  • клиент попытался подделать ценник в своем браузере - зафиксировать попытку подделки.

Касательно последнего - мне все больше нравится протокол gRPC+WebAssebbly - позволяет фактически сделать свой бинарные протокол с "ключом шифрования" - который будет сложно подделать

Но самое прикольно во всем этом - оказалось, что можно сделать еще и геймификацию на клиенте "Ожидается изменение цены, если вы обновите страницу - новая цена будет YYYY, успей купить по XXXX"