Даша Циклаури,
1. Если у вас есть очень хороший плюсовик, то такое можно проворачивать. Если нет - то ногу вы отстрелите сразу. И такое решение масштабируется с трудом (даже при хорошем плюсовике)
Зачем делать файл, если судя по всему, талон формируется не рандомно?
2. На хорошем железе 30к rps не встанет колом
Вам нужен толковый архитектор
Система не выглядит сложной, но судя по всему в ТЗ что-то дикое написано
Если ето логи и по ним не нужна мгновенная агрегация, то они масштабируются легко и просто
Те положили логи на диск, а через Х минут их батчем закинули в базу
А вот если по ним нужна мгновенная агрегация и поток запросов делать, то все сложно
Кеширование с радномными запросами не работает - у вас будет лишком много промахов
Все важнее цены
Точнее цену вообще уберите из функции принятия решения
Защита от рейдеров, хорошие отношения с органами, наличие в прошлом проблем с каналами и питанием, которые решили, наличие хороших знакомых среди персонала, которые дадут инсайд и тп
Нет тут никаких больших данных
Изменение данных "задним числом" чревато
Сколько операций прибавления добавления происходит по одному товару всреднем?
На каких запросах проседания по производительности, на сколько?
Какое железо?
Какие нагрузки?
1. Если у вас есть очень хороший плюсовик, то такое можно проворачивать. Если нет - то ногу вы отстрелите сразу. И такое решение масштабируется с трудом (даже при хорошем плюсовике)
Зачем делать файл, если судя по всему, талон формируется не рандомно?
2. На хорошем железе 30к rps не встанет колом
Вам нужен толковый архитектор
Система не выглядит сложной, но судя по всему в ТЗ что-то дикое написано