То есть, следите за логикой: они думают, что однажды я вспомню, что полгода назад написал что-то важное, захочу прочитать —  а архив доступен только по подписке! И я побегу покупать подписку? Ну не дураки ли? Зачем мне доступ к неактуальным для меня сообщениям? Ладно, я все.

Вы пишете 50 000 ежедневных рыл из поисковика, как будто это сильно много. Для личного проекта - возможно. Но для серьёзного - это копейки, потому что это (если исходить, допустим, из равномерной нагрузки), это меньше одного запроса в секунду - то есть очень мало. Понятно, что нагрузка, скорее всего, не равномерная,  но даже так вряд ли там хотя бы 100 запросов в секунду будет.

> Кеш для поисковиков начинается с HTTP 304

Замечательно. И как этот кеш инвалидировать?

> просто морфируя запросы

Как? Если у запроса параметров весьма ограниченное число, то все возможные результаты будут в кеше

> Конечно. Сообщения в чате — это драгоценные данные, которые надо хранить вечно.

Вы где-то видели в поисковой выдаче ссылки на страницы из чатов? Не форумов, а именно чатов с реалтаймом.

> Если человек сходу заявляет «без кеша нельзя», то он, скорее всего, просто обчитался хабрахабра

У меня в конторе есть проект, где тяжёлые запросы к БД. И в самом лучшем случае они выполняются за 40-60 мс. Выборка из Redis занимает раз в 10 меньше времени.

> Я тупо на постгресе велосипедю

При трафике 2 запроса в секунду (в среднем) это вполне имеет право на жизнь.

Не, простите, но я совсем все.

Ок)

а есть у вас на примете какой-то телеграм-чат (канал) где всякие бэкендерские штуки обсуждают?

Есть неплохие чаты по NestJS и по Starlette/FastAPI. Но именно какого-то общего по бэкенду нет, хотя в этих двух общие вопросы по бэкенд-разработке часто обсуждаются (не только связанные с этими фреймворками).

всем привет, работаю над миграцией процедур c MS SQL на postgre, столкнулся с проблемой процедура с простым select на MS SQL выдает данные, а на posgre нужно извращаться и писать return table и чтото типо такого, кто сталкивался с таким и как решал эту проблему?

А в чём проблема? Исторически в PostgreSQL были только функции. Хранимые процедуры появились не так давно, в 11 версии. И, насколько я помню, вернуть таблицу они не могут, только выходные параметры.

Почему решили мигрировать, если не секрет?

Сравни по стоимости ...

Доброй ночи, подскажите пожалуйста, можно ли на уровне БД настроить условие, если в одной таблице ставится false, в другой таблице должен изменится статус в поле по ключу?
или делать такое только в рамках приложения можно?

например
users
groups ( ключ user_id -> users.id)

Если в users поставить пользователю active=false, чтобы в groups по полю user_id тоже проставился false

Триггер?

та можно триггер, но может нет такой практики, если у меня rest api приложение, может все надо в рамках приложения настраивать

Это бесконечные споры обычно, где это делать))

Можно на уровне приложения в транзакции делать. Можно на уровне БД в триггере. Я бы на уровне приложения делал. Но это не значит, что это правильно.

Скорее всего, вам поле во второй таблице на фиг не нужно.

большинство тех, кто в работе юзают Слак покупают

когда бизнеспроцесс в чатах, то без истории никак

+