: D

вообще наверное можно как-то придумать

Не дорого игла от aws стоит?

Тем более в хайлоаде

Дорого, потому и слезли.

Я долгое время искал стриминговую площадку, чтобы грузишь mp4, он транскодит в hls и дает ссылку с on-demand access

Сервисов 20 поюзал, вплоть до энтерпрайз IBM. В итоге остановился на собственном решении, которое можно вынести в микросервис и радоваться жизни

На aws такое можно делать, но задействовует вроде целую цепочку сервисов. Крайне нерентабельно, тем более учитывая что мы стартап)

FFMPEG сила!))

Кстати, снявшись с тормоза: ObjectId можно удобно хранить в реляционных базах как int32 + int64, причём int32 будет таймстампом.

просто это, мягко говоря, много лишних данных )
если вместо 12 байт хранить 4, то и индексы будут в 3 раза меньше

Ну так монга делалась сразу с учётом масштабирования из коробки. Это очень умный ID, если вдуматься: там есть timestamp для грубой сортировки, есть серверо-зависимая сигнатура, есть энтропия и младшие байты - итератор для точной сортировки. То есть из этого id можно вытащить дофига полезной информации, он намного полезнее обсуждаемого как раз uuid v1, и при этом короче. И его можно при желании генерировать на клиенте.

И можно отличать, какие сгенерены на клиенте, на сервере, и на каком именно сервере из реплик/шардов.

только в твоем кейсе это все не нужно )
ты даже дату отдельным полем хранишь

Это id юзеров.

То есть, это timestamp, когда юзер зарегался)

я так полагаю, что вопрос «зачем везде таскать дату регистрации юзера?» не уместен?)

я понимаю что это совпадение)

просто не подумали )))

Правильно вопрос звучит "зачем везде таскать за собой дату добавления документа в коллекцию". И ответ "потому что это удобно со многих точек зрения: знать когда и каким сервером была добавлена та или иная запись".