lega

Я бы все эти поля хранил бы в счете (аккаунте), см. надежный перевод денег со счета на счет: https://docs.mongodb.org/manual/tutorial/perform-t...

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

Вы админов в базу добавили? (без них в каких то версиях auth не включается)

все равно можно удаленно подключиться анонимно.

Попробуйте выполнить запрос на получение/изменение данных, возможно доступа все же нет.

было принято использовать микросервисную архитектуру
все было понятно, то здесь не очень.

Похоже на "Поди туда - не знаю куда".
А цель какая? Это ведь тоже надо рассматривать как "инструмент по задаче". Расходы времени точно вырастут. Если попробовать/поиграться - то ок.

Есть ещё 3-й тип, когда делается монолит но с изолированными компонентами (микросервисами) внутри - нет столько возни деплоя как с микросервисами, и нет затрат (сетевых) на вызов микросервиса. А когда приходит реальная необходимость выделить компонент в микросервис, то он легко отпочковывается.

Можно установить "флаг" (например blocked: 123), и при каждом изменении документа проверять его.
см https://docs.mongodb.org/manual/tutorial/perform-t...

список топиков отсортированных по дате последнего сообщения в них для него

Для этого в топике нужно хранить дату последнего сообщения.

В теории такой запрос можно сделать на AgregationFramework, но он не будет использовать индексы, а значит будет полный проход по коллекции, а значит будет тормозить когда база вырастет.

Даже если бы вы использовали SQL, такая колонка была бы желательна, и необходима для худшего случая.

Первый вариант ещё делится на 2: хранение свойств в документе пользователя, и хранить свойства в документе друга.

Если все (или много) свойств нужно получать каждый раз (часто), то 1-й вариант лучше, т.к. будет давать все данные за минимум запросов, и это может работать в сотни/тысячи раз быстрее чем возня с миллионной коллекцией.
Так же тут будет экономия на индексах, + лучшее сжатие данных.

Если вам нужно за раз только одно/два свойства, то скорее 2-й будет лучше.

Также нужно учесть лимит в 16мб на документ.

во втором случае цикл становится бесконечным?

Потому что в результате получается "бесконечность" в дробной части. (так работает double/float)

>>> x = 100.475
>>> x - 100
0.4749999999999943

Их нужно откомпиллировать (прибиндить), https://docs.angularjs.org/guide/compiler

https://docs.angularjs.org/api/ng/filter/limitTo

1 - встречалось в поле properties 350 раз
2 - встречалось в поле properties 100 раз

Для этого можно держать кеш: {_id: 1, count: 350}

db.collect.find({"properties": {$all:[1]}})
Когда элемент один, лучше так:
db.collect.find({"properties": 1})

1) Лучше всего использовать готовую диреткиву для этого, под bootstrap она должна быть.
2) С датами лучше оперировать типом Date а не в строковом.
3) triggerHandler - это ангуляроская мулька, сделайте нормальное js событие - new Event('change') и dispatch его в элемент, тогда модель должна среагировать.

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