Под историю - своя база, а для текущих сессий чата другая. Для текущих чатов можно даже использовать какое-то временное хранилище, а не отдельную базу.
"Серебряной пули не бывает". Если вы думаете, что графы решат все проблемы, то вы ошибаетесь. Очевидно, что оно все рано или поздно упрется в быстродействие/производительность или масштабируемость.
psql + mongo это лишь мое предположение, мысль, которую я хотел до вас донести - не нужно использовать nosql для реляционных данных.
А если завтра вас заставят писать 1с, тоже задумываться будете? А что они зарабатывают не плохо, я слышал.
Если вас на работе заставляют делать что-то, что вам не нравится, то нужно увольняться и заниматься тем, что нравится. Корректировать свою специализацию под нужны работодателя - это глупо, вы сами должны делать этот выбор.
@font Вы заблуждаетесь. Любая современная SQL БД способна обрабатывать огромное кол-во запросов, этого хватит любому интернет магазину. В 99% случаев "медленной" базы виноваты программисты, которые не в состоянии правильно эту базу спроектировать и использовать.
Сложно сказать что-то по конкретным названиям изданий, подскажу только направление поиска. Можно начать со школьного учебника старших классов по физике, а потом на сайте любого тех вуза поискать ссылки на современную литературу по электронике, например вот www.ph4s.ru/book_electronika.html .
Ах, вам бекенд надо для игры. Простите, я слишком далек от такого рода проектов, да и сложно представить себе, что на уроках информатики будут работать над игрой, у которой есть (!) бекенд. В моем представлении это такой кривоватый прототип, бегающие квадратики и не более. К тому же скучно, наверное, разрабатывая игру писать код для бекенда.
Так вот в это и дело - вроде бы не очередь сообщений нужна, а шедулер какой-нибудь внутренний. Можно сделать это очередью с помощью Celery, но это идеологически подход немного не тот, плюс придется тащить зависимости и поднимать брокера.
