Пришла ко мне задача по перепроектированию системы лояльности, для одного из крупных интернет-магазинов. Понятно, что у системы лояльности десятки миллионов пользователей и многие тысячи запросов в секунду. Функционально, система работает хорошо, основная цель перепроектирования – решить вопросы масштабируемости и улучшить скорость ответа. При этом, хочется еще и гибкости, возможности добавления нового функционала, о котором сейчас никто не думает, без существенных трудозатрат и без модификации архитектуры.
Накидал уже несколько вариантов архитектуры, подумаю еще, может еще варианты придумаю. Каждый из вариантов, насколько вижу, удовлетворяет нефункциональным требованиям в части масштабируемости и ускорения скорости ответа. По гибкости к изменениям, есть некоторая разница. Так, можно задействовать шардирование с использованием PostgreSQL, а можно все хранить в key-value, например в Кассандре. Можно, под каждый тип параметра расчета, делать свой микросервис агрегатов, а можно в одном месте агрегировать данные. Или вообще их не агрегировать, просто кидать из очереди в шарду, а там использовать для вычислений по запросу.
Поискал в инете, что-то каких-то интересных референсных архитектур не нашел. Может кто видел такие примеры? Было бы интересно посмотреть.
Занимался ли кто проектированием систем лояльности, может поделиться с какими проблемами сталкивался? На что там стоит обратить внимание, какие моменты могут быть наиболее проблемными?

Здравствуйте, andsm, Вы писали:

A>Пришла ко мне задача по перепроектированию системы лояльности, для одного из крупных интернет-магазинов. Понятно, что у системы лояльности десятки миллионов пользователей и многие тысячи запросов в секунду. Функционально, система работает хорошо, основная цель перепроектирования – решить вопросы масштабируемости и улучшить скорость ответа. При этом, хочется еще и гибкости, возможности добавления нового функционала, о котором сейчас никто не думает, без существенных трудозатрат и без модификации архитектуры.
A>Накидал уже несколько вариантов архитектуры, подумаю еще, может еще варианты придумаю. Каждый из вариантов, насколько вижу, удовлетворяет нефункциональным требованиям в части масштабируемости и ускорения скорости ответа. По гибкости к изменениям, есть некоторая разница. Так, можно задействовать шардирование с использованием PostgreSQL, а можно все хранить в key-value, например в Кассандре. Можно, под каждый тип параметра расчета, делать свой микросервис агрегатов, а можно в одном месте агрегировать данные. Или вообще их не агрегировать, просто кидать из очереди в шарду, а там использовать для вычислений по запросу.
A>Поискал в инете, что-то каких-то интересных референсных архитектур не нашел. Может кто видел такие примеры? Было бы интересно посмотреть.
A>Занимался ли кто проектированием систем лояльности, может поделиться с какими проблемами сталкивался? На что там стоит обратить внимание, какие моменты могут быть наиболее проблемными?

Несколько раз делал программы лояльности в рамках платежек. Никакой особой нагрузки там нет, какие там тысячи запросов в секунду, вряд ли даже до тысячи дойдет даже для очень крупных интернет-систем. Так что особых задач по масштабированию там нет, разве что в хранении истории, там да, можно сделать шардирование (или просто не хранить слишком долго). Микросервисы тут не особо нужны, в лучшем случае отделить собственно лояльность от аналитики (там разные БД нужны и разные типы запросов).
Но вообще ничего особенно сложного для любого современного нормального стека.

Здравствуйте, Дельгядо Филипп, Вы писали:

ДФ>Несколько раз делал программы лояльности в рамках платежек. Никакой особой нагрузки там нет, какие там тысячи запросов в секунду, вряд ли даже до тысячи дойдет даже для очень крупных интернет-систем. Так что особых задач по масштабированию там нет, разве что в хранении истории, там да, можно сделать шардирование (или просто не хранить слишком долго).

Посмотрел, прямо сейчас несколько тысяч запросов в секунду к системе
лояльности. Интернет-магазин из топ10 России, плюс крупная розничная торговая сеть. Данных у системы лояльности сейчас относительно немного, около 300 Гб, история долго не хранится.
Сервера основательно нагружены, уже упираемся в пределы вертикального масштабирования.

Здравствуйте, andsm, Вы писали:

A>Накидал уже несколько вариантов архитектуры, подумаю еще, может еще варианты придумаю. Каждый из вариантов, насколько вижу, удовлетворяет нефункциональным требованиям в части масштабируемости и ускорения скорости ответа. По гибкости к изменениям, есть некоторая разница. Так, можно задействовать шардирование с использованием PostgreSQL, а можно все хранить в key-value, например в Кассандре. Можно, под каждый тип параметра расчета, делать свой микросервис агрегатов, а можно в одном месте агрегировать данные. Или вообще их не агрегировать, просто кидать из очереди в шарду, а там использовать для вычислений по запросу.

Структуры данных зависят от запросов и только от запросов. В целом, шардинг по user_id выглядит достаточно разумным решением.

И да, количество запросов выглядит нереальным, это уровень алиэкспресса или амазона, а не российского интернет магазина. Скорее всего, вам нужео избавляться от лишних запросов, а не пытаться масштабировать плохую архитектуру