Всем доброго вечера Разрабатываем чат-приложение с кастомными видами сообщений (разные типы/подтипы,

разные уровни доступа к сообщениям).
Уже сейчас насчитывается 6 различных паттернов доступа к истории, плюс есть еще вероятность, что их количество увеличится в двое.
Плюс сервис должен будет выдерживать пиковую нагрузку в 10к на начальном этапе, в перспективе больше.
Подскажите, какие сервисы стоит рассматривать в качестве хранилища истории сообщений для такой задачи?
Пока рассматриваем аврору, динамо, рдс + ручное поднятие монги или кассандры в екс.
От документ-дб и кей-спейсес пока что отказались, так как непонятен уровень совместимости с монгой/кассандрой.

Глянуть в сторну Pulsar может,

А как именно вы рассматриваете ?

А какие требования к latency? Плюс 10к запросов - наверное кешировать многое можно?

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

По лэтенси не критично, но до секунды это нормально. 10к в контексте чатов - это только новые сообщения (вставки).

Если 10 к на чтение ,то выдержит любая база. Если это на запись , то реляционка потянет только на ssd, если вы планируете делать commit после каждой вставки .т.е это скорее будет предел для Авроры,postgre,mysql И в дальнейшем вам нужно будет делать шардирование и разносить чаты по разным инстансам. Т.е у вас будет много инстансов mysql, например и вы будите в приложении или где -то ещё делать роутинг на нужный инсианс. Ну или взять диманодб.

10к - подразумевается на запись (делаем чаты, и там чтение происходит намного реже, чем запись). да, коммит после каждой вставки. по поводу ограничения спасибо, будем иметь в виду. новые сообщения будут пересылаться через message-broker + websockets. чтение будет происходить для подгрузки исторических сообщений.

ну вы там написали еще и коммит (fsync?) после каждой вставки, это прям сурово для чатика... RDBMS с single master масштабируется шардированием (после невозможности scale up) но это удовольствие то ещё )) Возможно Динамо и ваш вариант, вы там писали что на каждый паттерн нужен отдельный индекс но это далеко не всегда так..

а что такого в коммите после каждого сообщения, если цель не потерять ниодного сообщения?

Да ничего собственно, просто просадка по производительности по сравнению с фсинк каждую секунду. Дешевле параллельно хранить последние 5 минут в редисе или очереди. Я наверно вообще в базу не писал напрямую сразу а в кинесис или кафку. А сообщения передавал через паб саб