На практике разработки брата Тарантула, это решалось: выносом записи в лог в отдельный тред (на самом деле, процесс) и асинхронным общением с ним + тротлингом записи снапшота.

Сейчас в тарантуле отдельных процессов нет. Запись в лог и запись в снапшот происходят в выделенных тредах, и общение с ними основного потока асинхронное: записи в лог могут ждать одновременно много транзакций, и read-only транзакции ни чего не ждут.

А ещё в tarantool протокол асинхронный: не нужно держать по коннекту на каждый поток выполнения, т.к. операции могут переупорядочиваться. Если поток приложения A послал команду write, потом поток B послал read, и write ждёт записи в лог, то ответ на read вернётся раньше, чем ответ на write.
Меньше коннектов - больше возможностей для буферизации - меньше оверхед на сисколы и в самом сервере, и в клиенте.
Экономия sys cpu бывает до 40% (обычно в районе 5-10%).

А главное, с асинхронным протоколом легко писать аккумулирующий прокси, чтобы сто бэкендов запихивать в несколько коннектов. Таким образом экономя cpu сервера БД.

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

плюсую, есть такое ощущения, что для большинства задач это минусы вообще не актуальны. основной плюс редиса - он дико популярен, его можно взять и воткнуть, берите тарантул - эти дополнительные трудозатарты, если ваши сотрудники с тарантулом дел вообще никогда не имели.
кстати, если угорать по производительности, а что если идея с отдельным kv это в прицнипе так себе? так как во взятии по ключу задейстсована сеть + парсинг ключа в значение/структуру целевого рантайма, чтобы его использовать. и тогда надо обмазаываться всякими фреймворками а-ля hazelcast или openHFT, чтобы кеши были встроенным в сервсис, а группы сервисов сами по себе ещё являлись распределённым кешом, который в фоне обновляется, а доставание объектов из него теперь представляет просто обращение к мапе или иной родной структуре в рамках яп, без всяких походов по сети и парсинга.

Redis отлично ложится логически на структуры и примитивы типа в очередей в ЯП, по сути просто реализуя их "вовне". Tarantool - это своя "вселенная", к ней нужно адаптироваться и адаптировать код. Так что да, если речь не идёт о гигабайтах чего-то, то Redis - отличное решение, к тому же масштабируемое. Мне вот не нравится дико, что в Sentinel режиме нельзя пользоваться номерами баз и вызовом select.

Так-то понятно, что если Redis не тянет - нужно использовать что-то сложнее, но это же не значит, что для решения любого масштаба нужно сразу выкатывать пушку и хренарить из неё по воробьям

Я все не понимаю решением чего он является

Хранения и записи структур данных вне процесса?

Собственно, для IPC между процессами, в том числе на разных хостах через сеть

С учётом того, насколько геморройно реализован IPC типа POSIX/SystemV даже в рамках одного хоста - ну как бы Redis удобнее и без всякой сети.

Да, даже если у вас внешнее kv хранилище, и оно супер-пупер быстрое, всё равно нужно обмазываться локальными in-memory кэшами, т.к. парсинг действительно тормозит.

Для этого всегда есть более интересный персистенс под рукой

Да скоростной кэш как правило никому и не нужен, разница между достать из основного хранилища или из мемкэша одну и ту же структуру как правило минимальна. Держать какой-нибудь к/в перед хранилищем интересно в первую очередь с точки зрения наличия двух точек отказа вместо одной, то что он может выиграть пару миллисекунд (да, мы живём уже в эпоху ссд) обычно большой роли не играет

Например???

В котором приложение хранит то, что не может потерять

Если мы говорим про классику, то редис всегда появляется после mysql

И зачем его внедрять, когда уже есть база - я хз.

Нужно хранить переменные, обмениваться ими с другими процессами. Они временные. И?