Эмм, но если решение занимает время, то мы получим то, против чего боролись кэшем. То есть в кэше и в бэке в некоторых случаях будут разные данные.

Ну и конечно нарушается принцип единого интерфейса доступа к одним и тем же данным.

Во-первых, надо смотреть на кейсы. Кэш нужен не всегда

Во-вторых, единый интерфейс нужен только к модели на запись. Моделей на чтение может быть несколько. Разным клиентам нужны разные срезы модели под разные сценарии запросов

Из кэша вытащить одно, из бэка другое. Но ты прав, это инженерная задача.

Что такое бэк?)

Условное хранилище данных.

Я это к тому, что один и тот же запрос в одно и то же время к двум эндпоинтам  может дать разные результаты.

Посмори CQRS, у репозитария (хранилища) много представлений. Кэш - это часто, одно из представлений на чтение (модель на чтение)

Вот и я за "кэш на чтение", со стороны пользовательского приложения.

А тут нет разницы между кешами и разными хранилищами. Вот у меня поток данных по пользователям. Я их складываю в oltp хранилище, в аналитическую БД (с обогащениями), в эластик (кусочки) для полнотекста. С какой-то точки зрения и аналитическая БД и эластик - это кеши (нужны для ускорения специфических операций). Могу и в какой-то редис ещё добавить.
Разве что не синхронно, конечно, добавляю.

Полностью разделяю данную точку зрения.  
Если вы используете экспериментальные или просто редко используемые другими функции продукта - всегда есть риск того, что они либо не работают как надо, либо не тянут нагрузку.  Поэтому и интересно услышать в каких конкретно кейсах не удалось применить Ignite - что примерно пытались сделать. Мы же тут вроде собрались для обмена премудростями?  Про историю с "золотой записью клиента" в Сбере я немного слышал, как по мне - это чистой воды авантюризм.
Про кейс, в котором не удалось применить, например, hazelcast, я рассказал - достаточно высокая нагрузка на запись, распределённый кэш.  Симптомы: блокировки, таймауты, повисшие треды, как результат - остановка приложений PoC под нагрузочными тестами. Тюнинг параметров хазелкаста и jvm результатов не дал, исследование исходников хазелкаста с целью обнаружения проблем в задачи не входило. Было это довольно давно, надеюсь с тех пор там всё починили. Ignite с той же нагрузкой справился без проблем.

А тут нет разницы между кешами и разными хранилищами. Вот у меня поток данных по пользователям. Я их складываю в oltp хранилище, в аналитическую БД (с обогащениями), в эластик (кусочки) для полнотекста. С какой-то точки зрения и аналитическая БД и эластик - это кеши (нужны для ускорения специфических операций). Могу и в какой-то редис ещё добавить.
Разве что не синхронно, конечно, добавляю.

Достаточна высокое - можете поделиться конкретными цифрами?