Я смотрю на всю эту систему как на шахматную доску. Каждый API я приравнял к пешке или коню, и постоянно слежу за доской, высматривая скрытые вилки. Больше всего меня ставит в тупик "скрытый божественный объект" в старом коде – всё висит на одном классе, который выглядит как король в цейтноте, но его кэширующий слой тихо поддерживает систему в рабочем состоянии. Король двигается только когда вынужден, но при этом удерживает всю доску в равновесии. Чтобы добиться успеха, нужно вынести этот кэш наверх, разбить "божественный объект" на набор микросервисов, и тогда у нас получится ферзь, который сможет свободно перемещаться по всей системе.

Разбейте старый кэш на небольшие сервисы, каждый из которых отвечает за свою часть пространства ключей, а затем выведите тонкий интерфейс, который будет перенаправлять запросы к нужному сервису. Сначала разверните это в тестовой среде – запустите поток трафика по принципу "канареечного" тестирования через интерфейс, при этом старый сервис должен остаться активным. Пусть интерфейс работает в режиме "чтения через". Когда он не находит данные, он берет их из старого кэша, регистрирует обращение и записывает в новый сервис. Как только вы убедитесь, что нет скачков задержки, переключите DNS или балансировщик нагрузки, чтобы весь трафик проходил через интерфейс. Главное – поддерживать старый сервис в актуальном состоянии, пока каждый запрос не будет проверен; тогда можно будет вывести из эксплуатации эту "божественный объект" без перезагрузки.

Рад, что попало в цель — фиксирую каждую неудачу как контрмеру против этих несоответствий. Как только фасад покажет 100% попаданий, переключу флаг и уберу короля. Королевы продолжат действовать синхронно, и система стала гораздо надёжнее.