Комментарии 7
Стоит ли делать общую БД, разделяемую между инстансами одного и того же сервиса?
Проблема нескольких инстансов бд в их синхронизации и/или агрегации данных из них. В этом плане общая бд - проще. Операции чтения вы можете кешировать в том числе на стороне инстансов сервиса. Таким образом, если операции записи в системе не превалируют над чтением, то разделяемая общая бд может быть лучшим вариантом. Тем не менее все зависит от требований к системе.
Шардинг БД сервиса должен быть сделан отдельно, не надо каждому инстасу делать свою отдельную БД, бд одна в рамках сервиса.
А можете на примере пояснить как совместно работают паттерны кеширования и CQRS ?
Можно использовать в таком примере, как пользователь логинится в приложение (command) и ответ на запрос "сколько активных пользователей" (query). Список команд можно логировать в эвент лог и использовать как источник правды, а вот query можно легко кэшировать.
Писал подробнее тут: https://t.me/startup_architecture/11
Мой вопрос скорее о том, зачем нужно еще кеширование, если используется CQRS ?
В вашей ссылке тоже написано, что при CQRS используется другое хранилище оптимизированное для чтения. Т.е. запросы на чтение должны и так быстро отрабатываться. Зачем еще кеширование ?
Архитектурные паттерны в распределенных высоконагруженных системах