02-social-feed: обзор со свободным припоминанием
Промпты на свободное припоминание по кейсам соцленты. Реконструируй каждый дизайн по памяти — пайплайн уведомлений, гибрид fan-out ленты, push/порядок чата, предвычисление автодополнения — до того, как откроешь образец.
Припоминание бьёт перечитывание. На каждый промпт реконструируй полный дизайн по памяти — пайплайн, компромисс, режим отказа — до того, как откроешь образец. Усилие пересборки архитектуры и есть то, что закрепляет эти четыре кейса.
Пересобери каждый дизайн без подглядывания: пайплайн fan-out уведомлений и что предотвращает шторм ретраев; компромисс fan-out ленты и гибрид знаменитостей; транспорт push, порядок и галочки доставки чата; и почему автодополнение предвычисляет всё офлайн.
- 01Реконструируй пайплайн уведомлений и три куска, предотвращающих шторм ретраев.
- 02Назови компромисс fan-out ленты, отношение чтение:запись, что его решает, и гибрид знаменитостей.
- 03Объясни транспорт чата, правило персист-до-ack, порядок и три галочки.
- 04Почему автодополнение обязано предвычислять и как trie с top-k на узле отдаёт за O(1)?
Если можешь пересобрать каждый дизайн по памяти, ты держишь спину юнита. Система уведомлений — асинхронный пайплайн fan-out, чей шторм ретраев предотвращают backoff+джиттер, DLQ с ограниченными ретраями и ключ идемпотентности. Лента новостей дефолтит в push (read-heavy, ~100:1), но тянет знаменитостей в гибриде, ведь степенной хвост ломает единую стратегию. Чат — server-push по WebSocket, маршрутизируемый через реестр соединений, персистит до ack и упорядочивает сообщения seq в диалоге. Автодополнение предвычисляет top-k на узле trie офлайн и отдаёт O(1) чтение за edge-кешем, никогда не ранжируя вживую на нажатие. Сквозная нить: на этой глубине каждая read-heavy соцсистема двигает дорогую работу на сторону записи или сборки, чтобы путь к пользователю был дешёвым, безопасным лукапом.
Что-то непонятно?
Задай вопрос по этому уроку. Вопросы анонимны и попадают напрямую автору — урок станет лучше.