Иван Шумов

CQRS и кэш никак не связаны. Есть разные стратегии кэширования и их надо выбирать под задачу. Надо понимать что есть 2 базовых метрики: cache miss и cache hit. Если у вас миссов сильно много то надо обновлять кэш в фоне. Если нет то можно это делать при запросе

В CQRS первое C - Command. На сервер отправляются команды, а потом одним из доступных вариантов получают ее статус согласно идентификатору задачи. Способов много: от рекуррентных запросов к api до push и вебсокетов

В общем случае все решается через ABAC. Что же касается списочных элементов то надо понимать несколько моментов:
- какая цель разграничения
- какая организация ресурсов

По моему опыту в большинстве случаев пробуют подменить организацию ресурсов - системой прав доступа. Надо понимать что это независимые, но часто последовательные процессы.

Возьмём пример - пользователи и проекты в jira. Права описывают доступ к проекту, но никак не влияют на список проектов. Вместо этого в jira хранится ассоциации между проектами и пользователями.

Можно рассмотреть также древовидную структуру ресурсов где права могут разделяться по маске, например:
/resource_type/resource_group/random_prefix*

Не будет тут профильной литературы, как и четкого ответа на вопрос. Вернее как понять архитектуру готового сервиса - никак, это коммерческая тайна.

А как построить такой сервис - сформулировать требования к сервису и спроектировать архитектуру под эти требования. Вариантов - миллион

Очереди. По сути есть 2 варианта:

• Простой. Мы создаем очередь и в ней обрабатываем последовательно все операции одним обработчиком без масштабирования. Подойдет для старта на небольших нагрузках
  
• Сложный. К простому варианту добавляем слово Kafka и партицирование по ключу клиента чтобы команды от одного клиенты попадали в одну партицию топика. Надо иметь больше опыта, но зато на больших объемах отлично масштабируется
  

То ли у меня наступает синдром микроскопа, то ли день сурка. Читаем про ABAC, Casbin или Open Policy Agent

Начать со списка функциональных, а потом и не функциональных требований. Если нет четкости то согласовать и устаканиться первичные, а по мере работы уже что-то корректировать. Технологии особо роли не играют в такой постановки вопроса. Как и архитектура ПО

https://camunda.com и аналоги в помощь. Если это подходит под логику бизнес-процессов и BPMN
https://zeebe.io попроще и использует не только нотации BPMN.

Визуализацию можно уже прикручивать самостоятельно или использовать готовые моделлеры. Вроде хвалили вот эту штуку https://www.flokzu.com

Confluence + Lucid (или draw.io как плагин в confluence)

Как раз таки S3. Надо понимать что кроме s3 задействуется cdn, а для старых картинок есть lifecycle policy по которому со временем они переводятся на более дешевое хранилище за счет крепкого обращения, а потом так и совсем удаляются