Обновление центрального кеша с изменением различных системных данных в масштабируемой архитектуре микросервисов

Мы создаем микросервисную систему, в которой новые данные могут поступать из трех (или более) разных источников и которые в конечном итоге влияют на конечного пользователя.
Неважно, какова цель системы для вопроса, поэтому я действительно попробуй сделать просто. Пожалуйста, смотрите прилагаемую схему.

Данные могут поступать из следующих источников:

1. Сайт бэк-офиса: определите конфигурацию системы и пользователя.
2. Основной сайт: место, где пользователь взаимодействует с сайтом и совершает действия.
3. Данные из внешних источников: например, партнеры, которые могут предоставить дополнительные данные (дополнительную информацию) о пользователях.

Услуги:

1. Служба бэк-офиса сайта: обслуживание сайта бэк-офиса.
2. User-service: обслуживать основной сайт.
3. Служба импорта: импортирует дополнительные данные (дополнительную информацию) из внешних источников.
4. Служба пользовательского кэша: синхронизируйте все вышеуказанные системные данные и объедините их в заранее подготовленные ответы кэша. Причина этого в том, что основной сайт должен обслуживать сотни миллионов пользователей и работать с очень низкой задержкой.

Основная идея:

1. У каждого микросервиса своя БД.
2. Каждый микросервис может масштабироваться.
3. Каждое изменение данных в одной из трех частей влияет на пользователя и должно быть отправлено в службу кэширования, чтобы в конечном итоге это отразилось на основном сайте.
4. Кэш (Redis) содержит все данные, объединенные в заранее подготовленные ответы для основного сайта.
5. Каждое изменение данных службы будет опубликовано в теме pubsub для службы кеша для обновления базы данных Redis.
6. Система должна обслуживать около 200 миллионов пользователей.

Итак... вопросы: .

1. поскольку служба пользовательского кэша может (и должна) масштабироваться, что произойдет, если, например, на pubsub ожидаются два сообщения с данными об обновлении, одно старое, а другое новое. как обрабатывать только новое сообщение и предотвратить случай, когда один экземпляр службы кеша обновляет данные нового сообщения до Redis и только после того, как другой экземпляр службы кеша переопределяет его старым сообщением.
2. Также бывает случай, когда экземпляру Cache-сервиса нужно сначала прочитать текущие пользовательские данные кеша, внести в них изменение и только потом обновить кеш новыми данными. Как предотвратить случай, когда два экземпляра, например, читают текущие данные кеша, а третий экземпляр обновляет его новыми данными и переопределяет его своими данными.

3. Можно ли вообще заранее подготовить ответы на основе нескольких источников, которые могут периодически меняться?? каков правильный подход к этой проблеме?