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