Почему так было: потому что очень много чтения/записи. Но так жить нельзя, потому что файл ломается при синхронизации. Это было десятилетнее легаси.
Условия: держать десятки миллионов операций чтения/записи в секунду (т. е. работать в памяти, без вариантов). Формат данных: несколько значений к ключу.
Для этого хорошо подошёл редис, который и впилили.
После этого старый монолит кода начали разбирать на куски — выносили кусок, в котором нужно было сделать at-least-once доставку уведомлений. В качестве очереди использовали тот же редис. Эдж кейс — если сервер сдохнет в момент отправки сообщения, то сообщение останется «взятым» из очереди». Каждые эн минут по определённым условиям сервер отправки уведомлений забирает сообщения обратно в очередь. Это допустимо, потому что даже если оно было уже отправлено, мы имеем право отправить его ещё раз.
Новый сервис был написан с использованием mypy, протестирован юнит-, интеграционными и мутационными тестами, поэтому вообще не потребовал никаких изменений с момента того, как был в тестовом режиме выкачен (и до сих пор, насколько мне известно, так и работает).

Для меня это не великий таск а очередной бизнес костыль

А я вот не понял есть ли у тебя голова почему там нельзя было использовать inmemory db в shred memory