Проектирование сервиса персональной ленты. Как решать System Design?

[BincomAD]

Если хотите попасть на следующий стрим по System Design, разбору алгоритмов или просто задать вопросы - подписывайтесь на канал: https://t.me/siliconchannel и на канал c анонсами: https://t.me/silliconanouncment

[BincomAD]

Если хотите попасть на следующий стрим по System Design, разбору алгоритмов или просто задать вопросы - подписывайтесь на канал: https://t.me/siliconchannel и на канал c анонсами: https://t.me/silliconanouncment

[rpc1]

И такую задачу надо решить за 50 минут!

Что не хватает: не нашел обоснование выбора Postgres, Kafka, Redis (например у AWS есть свои альтернативы)

От себя бы добавил в решение: использование самого дешевого хранилища для старых картинок. Например через месяца 2 они протухают и переносятся в медленное хранилище. Это сэкономит кучу денег.

[BincomAD]

Согласен. Вообще в этом решении еще миллион всего можно улучшить и обсудить, но сисдиз это процесс такой, бесконечный)

[SabMakc]

В ленте подписчика храним не пост, а указатель
Когда фан-аут воркер видит, что автор - инфлюенсер, он кладёт в ленту подписчика не post_id, а специальную метку, например influencer:{author_id}.

И в чем выгода? Все равно все 10М подписчиков перебираются на каждый пост инфлюенсера. Разницы с "добавить post_id в ленту подписчика" нет.

Если уж делаем гибрид - то читаем ленту и читаем список подписок. И из списка подписок выбираем инфлюенсеров и их посты. И мержим это все вместе.

Описанная схема полезна разве что для тех, кто очень много контента генерирует - вместо "каждый post_id у каждого подписчика" получим "одна метка у каждого подписчика".

Post Service
...
Постов в ленте на пользователя: 20 (первые 20 записей, которые видны сразу).

Непонятно, как эти 20 записей соотносятся с идеей курсорной пагинации, заложенной в API.

В целом осталось впечатление, что разные части статьи писались в разных диалогах с ИИ (или просто в разное время). В целом получилось неплохо, но согласованности между частями как-то не хватает.

P.S. надеялся увидеть что-нибудь про CQRS, которым подобные вещи и решаются - но не увидел.
P.P.S. тема отказоустойчивости тоже не раскрыта.

[maxim_ge]

Выше @SabMakc отметил непонятность выгоды от записи метки в ленту подписчика — поддержу и добавлю несколько замечаний.

Kafka — это не брокер сообщений, а event streaming platform. Может работать как брокер, но это не совсем по назначению. Для описанных нагрузок (1000 RPS на запись) хватило бы Redis Streams или даже PostgreSQL с outbox-паттерном.

Совершенно непонятно, зачем в рамках этих требований потребовался Neo4j. Операции с подписками — это простые key-value lookups по двум индексам, никаких traversal на глубину 2+. Вот если бы нужно было строить социальный граф с анализом связей или искать кратчайший путь между пользователями — тогда да. А для INSERT/DELETE/SELECT по (follower_id, author_id) это overkill с болезненным горизонтальным шардированием.

Вообще, для таких нагрузок подобное видовое разнообразие технологий не требуется. S3 (или аналог) + PostgreSQL, или S3 + ScyllaDB.

У нас (https://untill.com/untill-air) как раз работает второй вариант в Hetzner: 5 узлов AX41-NVMe, 200 евро в месяц, CQRS, event sourcing. Тестовый стенд стабильно по ночам держит 4000 ops (запись). Три датацентра, падение одного система переживает.

[kest70]

Это базовый минимум что нужно знать, чтобы сегодня попасть в ИТ хоть с опытом хоть без.

[onets]

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

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