02-social-feed: обзор с выбором ответа
Синтез кейсов соцленты в формате с выбором ответа: fan-out уведомлений и шторм ретраев, компромисс fan-out ленты и гибрид знаменитостей, server-push и порядок в диалоге у чата, правило офлайн-предвычисления у автодополнения.
Четыре решения по четырём кейсам юнита — каждое из тех, что принимаешь в дизайн-ревью, а не определение для пересказа. Нить, связывающая их, та же, что в любой read-heavy соцсистеме: сделай дорогую работу раз, на стороне записи или сборки, а путь к пользователю держи дешёвым лукапом.
Подтверди, что назовёшь недостающий страж дедупа в шторме ретраев, проведёшь знаменитость через гибрид ленты, наложишь консистентный порядок чата без глобальной координации и отвергнешь автодополнение, ранжирующее вживую на нажатие.
- 01Почему ретраям уведомлений нужен ключ идемпотентности и почему ленте нужен гибрид?
- 02Как порядок чата и отдача автодополнения избегают дорогой работы на пути пользователя?
Четыре кейса рифмуются. Система уведомлений ретраит at-least-once, потому ей нужен ключ идемпотентности ради избегания шторма ретраев — ретраи без дедупа дублируют. Лента новостей read-heavy, потому толкает (fan-out-on-write) обычных авторов, но тянет знаменитостей в гибриде, ведь степенной хвост ломает единую стратегию. Чат упорядочивает сообщения seq в диалоге, назначенным на персисте — тотальный порядок там, где он важен, без глобальной координации — и дедупит по id сообщения. Автодополнение никогда не ранжирует вживую на нажатие; оно отдаёт предвычисленный top-k из trie, построенного офлайн, O(1) чтение за edge-кешем. Объединяющий принцип всех четырёх: сделай дорогую работу раз, на стороне записи или сборки, а путь к пользователю держи дешёвым, безопасным лукапом.
Что-то непонятно?
Задай вопрос по этому уроку. Вопросы анонимны и попадают напрямую автору — урок станет лучше.