Там было написано: 10к RPS на запись, 3к - на чтение.

ну для примера appodeal у меня держал 300к rps суммарно на ~150 серверах, при том что основная часть была на... рельсах) вобщем из спортивного интереса покурю на досуге

В этом сервисе основная сложность - это общая глубина хранения в 30 дней, что выливается в эпические сотни миллиардов записей и необходимость их тримать аккуратно (спойлер: триммингом занимается TTL-индекс).

Облака к нам в очередь выстраиваются) Нет, контент в рамках. Edgy, но не более того. Модераторов жалко, конечно, но, говорят, что в Фейсбуке ещё хлеще.

да это усложняет, но есть сильное ощущение что задачу можно решить элегантнее что даст сильную экономию в ресурсах, я в первую очередь это имею ввиду а не оптимизацию кода/хранилища, хотя с хранилищем такое же ощущение, что mongo тут overkill и на ней сэкономить можно очень существенно

да это усложняет, но есть сильное ощущение что задачу можно решить элегантнее что даст сильную экономию в ресурсах, я в первую очередь это имею ввиду а не оптимизацию кода/хранилища, хотя с хранилищем такое же ощущение, что mongo тут overkill и на ней сэкономить можно очень существенно

Вообще решение действительно очень прямолинейное, но у него есть простое обоснование: сервис очень важен для продукта, при его отказах раз в 3-4 месяца метрики сразу втыкаются в землю: люди открывают приложение, видят то же самое, что уже видели, и тут же закрывают.

Мы думали вообще хранить отметки о прочтении на клиенте, но опять же, у настойчивого юзера их может скапливаться тысяч 10 в месяц, непонятно как делать запрос на новый контент в таком раскладе.

а, ну это важно кстати, запросы на чтение истории они важны не для юзеров а для сервиса готовящего ленту контента для юзера, так?

Конечно. Клиент просто говорит: дай следующую пачку контента, limit 30. Рекоммендер умеет отдавать условно топ-1000 контента из пула, фильтровать не умеет, поэтому фильтрация идёт через сервис прочитанных.

А напомни плиз про период в 30 дней, откуда ноги растут? Неужели за 30 дней в пуле контента не набирается достаточно чтобы старый контент на глаза снова не попался?

Экспериментально подобран. Рекоммендер очень хорош (см. статью, кидал ссылку выше) , и реально выдаёт один и тот же контент в топе одному юзеру. Надо посмотреть, кстати, динамику изменения топа, но кажется, что полная смена контента в топ-200 будет происходить примерно раз в 2 недели. А просмотреть 200 можно за один заход.

Вот там настоящий rocket science: 12 GPU-серверов, модель переобучается каждые 10 минут)

На какой отметке роста вы начали заморачиваться с этим всем?

Не понял вопрос. На какой цифре DAU?

Думаю да, когда вы начали прямо всерьез делить на микросервисы?

Ну окей, вот, например, боевая задачка: сервис "отметки о прочитанном".

Сервис хранит 30 дней истории просмотров юзерами контента строками вида:

user_id int96, content_id string(10), timestamp int32

На базу идёт нагрузка в 10000 RPS на запись блоками от 1 до 10 строк. Итого в таблице постоянно хранится примерно полтора триллиона строк. Понятно, что таблицу надо обрезать не реже чем раз в сутки, при этом не блокируя остальных операций.

Также идёт нагрузка в 3000 RPS запросов вида: "вот список content_id размером не более 1000 элементов, верни мне те из них, которые не были просмотрены юзером user_id", т.е. которых нет в таблице.

Ну и всякая мелочь типа "дай мне историю просмотренного контента для юзера", суммарно скажем ещё на 2000 RPS, для ровного счёта.

Сколько реплик и шардов Постгри нужно для реализации такого сервиса, и с какого раза удастся так его написать, чтобы он отвечал не более чем за 50ms и имел среднее время между инцидентами не менее 3 недель, а время восстановления не более часа?  Вопрос со звёздочкой: как будем делать и хранить бэкапы?

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