тоесть можно иметь коллекцию юзеров и коллекцию тудушек, иметь связь между ними каким то образом и это ещё не означает что скл для этого лучше?

Да как ты такие выводы то делаешь?
Можно иметь кучу коллекций
Можно даже иметь в каких-то случаях связи между ними, хотя каждая связь должна заставлять задуматься, а точно ли монга подходит для этой задачи
Но в данном конкретном случае нет причин, почему тудушки надо хранить отдельно, и я написал, почему так считаю

причин нет потому что требований никаких не озвучено. С этим понятно.
Но если мы захотим показывать тудушки пользователя на конкретную дату, то уже легче будет хранить их отдельно.
Я понял тебя. Ранее думал что ты рофлишь с монги.

Чем легче то?
Точно так же в пользователе хранишь массив объектов - тудушек с датами, делаешь выборку по датам

на мой взгляд, проще фильтровать в отдельной коллекции, чем во вложенном массиве. И индексы проще так построить.

А чем проще?
Меньше буковок надо написать?
Ну так тогда не забывай, что доставать тудушки вместе с юзером сильно проще, если они в нём и лежат
А индексы можно строить по вложенным полям и по элементам массива

Пока что я не вижу преимуществ в том подходе который ты предлагаешь.
Надо сказать, что мнение зависит от знаний, опыта и возможно у меня их меньше чем у тебя. Поэтому пока понять тебя не могу.

А какие преимущества ты видишь в хранении тудушек отдельно от пользователя?
Упрощение агрегаций? Я спросил, в чём именно это упрощение выражено, ты пока не ответил 🤷‍♂
Ну и второй вопрос - а зачем использовать монгу, если строить модель данных, основанную на связях?

О какую дискуссию я начал своим вопросом😅

1 Да. меньше думать там где это возможно.
2 Не знаю. Для меня сейчас выбор не стоит. Знаю одну субд и это определяющий фактор. На этом аргументы заканчиваются. Про скорость, репликации, отсутствие схем, жс в бд и объемы  я лепить тебе не буду 😆

Можете кратко рассказать, как работают большие приложения с сотнями миллионов пользователей? В чём основная суть?
Вот есть у нас инстанс базы данных. Я так понимаю, что количество одновременных соединений к ней ограничено. Но при этом если раздробить её, то возникает проблема синхронизации (если делаешь запрос на одну базу, то не получишь изменения с других). Как это решается вообще? Как называются такие проблемы?
Как это реализовано в nodejs?

И я правильно понимаю, что если нам нужно иметь быстрый доступ с разных точек мира, то нужно развернуть разные сервера в разных точках планеты (чтобы был минимальный лаг между условной японией/америкой/европой), но как бд будет существовать в этом случае? Типа, будет отдельный сервер, который хранит одну бд (и которая выступает source of truth), а остальные синхронизируются с ней периодически?

либо шардинг, либо реплика master-slave, либо master-master

Чтобы такие вещи можно было реализовать, их нужно заранее предусматривать или их можно реализовать после запуска и какая-то специальная заранее подготовленная архитерктура (радикально другая, типа event sourcing'а) не потребуется?

большинство бд имеют встроенные инструменты

Окей, ещё вопрос. Можно же как-то настроить (балансировщик того же nginx'а), чтобы можно было менять продакшен инстанс приложения без остановки работы?
Например, я разворачиваю апдейт, убеждаюсь что всё хорошо, потом переключаю что-нибудь в nginx'е, чтобы он все следующие запросы направлял уже на новое приложение, а старое перестал использовать. И затем старое просто вырубаю и удаляю.
Если можно, как это называется/как гуглить?
Просто сейчас приходится всё приложение минут на 5 останавливаться, что не оч хорошо. Хотелось бы чтобы апдейты можно было без остановки выкатывать.

обычный port forwarding

еще можно так, что все запросы идут сразу на N приложений/сервисов, которые работают с репликой бд, таким образом получается почти реальная тестовая среда, как все готово и ошибок нет, меняется порт или тег/имя сервиса

Так всё равно же останавливать придётся, или нет?

sudo nginx -s reload