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

Сергей, подучитесь ещё немного - если получится - тогда вам возможно станет ясна история вашего "успеха". Если конечно очень хочется - feel free в личку, разъясню детальнее.

В любом более или менее зрелом продукте есть подмножество функций, которые точно работают. Поэтому любой практически продукт будет работать надёжно, если хорошо его знать и использовать только проверенный функционал. Если инфраструктура стабильна и нет большого потока обновлений, продукт будет работать стабильно годами. Как всегда, нужно на кейсы смотреть.

Ген, а глупый вопрос можно? Если назначение кэша - хранение часто используемых данных, нафиг туда писать сразу результаты обработки от фронта? Там же по идее результаты наоборот от бэка к фронту должны храниться.

Саш, ну не сразу. После некой обработки в потоке (сервисом)

Так зачем?

Просто если оно уже обработано, значит сохранено. Не?

Ну ты уже выполнил обработку, почему бы результаты не отдать сразу на чтение?

Нафига? Ресурсы сожрать, и хрен знает вдруг попросят?)

Не обязательно, у тебя модели записи и чтения могут быть относительно независимые, главное согласование в конечном итоге обеспечить

Хм. Согласен. Хочу кейс где это нужно посмотреть. Есть? Можно в личку.

Смотри. Кэш нужен явно зачем-то, то есть нужно быстро что-то зачем-то отдавать. Кейсы разные бывают. Вопрос, когда его обновлять? Почему бы не сразу после обработки.

Write-through: write is done synchronously both to the cache and to the backing store.

Посмотри для начала плз: https://www.amazon.com/Streaming-Data-Understanding-real-time-pipeline/dp/1617292281/

Проблема с гарантией консистетности?

Проблема с масштабированием ресурсов?

Нет ни каких проблем, это инженерная задача, её нужно просто решить

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

существует write-through cache, например DAX кеш для DynamoDB

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

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