Архитектура кэша Redis и Mongo для сохраняемости

Установка:
Представьте себе службу, похожую на Twitter, в которой пользователь отправляет сообщение, которое затем читают многие (сотни, тысячи или более )пользователей.

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

Имея это в виду, мое исследование, кажется, сильно указывает на направление использования кэша для 90%, а затем также для хранения сообщений в другой долговременной -постоянной системе. Итак, моя идея на данный момент состоит в том, чтобы использовать Redis для кеша. Преимущество заключается в том, что Redis работает очень быстро, а также имеет встроенный pub/sub, который идеально подходит для публикации сообщений для многих людей.Затем я рассматривал возможность использования MongoDB в качестве более постоянного хранилища данных для хранения тех же сообщений, к которым будет осуществляться доступ по истечении срока их действия из Redis.

Вопросы:
1. Выдерживает ли эта архитектура критику? Есть лучший способ это сделать?
2. Что касается механизма хранения сообщений как в Redis, так и в MongoDB, я думал о том, чтобы приложение выполняло 2 записи :1-ю -запись в Redis, после чего оно сразу же было доступно для подписчиков. 2-й -после успешного сохранения в Redis немедленно запишите в MongoDB. Это лучший способ сделать это? Должен ли я вместо этого заставить Redis отправлять сообщения с истекшим сроком действия в саму MongoDB? Я думал об этом, но не смог найти много информации о прямом переходе в MongoDB из Redis.