В современном мире мы привыкли к тому, что технологии должны быть безупречными: базы данных — полностью согласованными, задержки — минимальными, а доступность — непрерывной. Но в реальности достичь всех этих качеств одновременно крайне сложно. Именно эту мысль проводит автор блога Jaz в своей статье «When Imperfect Systems are Good: Bluesky's Lossy Timelines», описывая, как социальная платформа Bluesky сознательно пошла на «потери» в таймлайнах ради повышения скорости и стабильности системы.
Что такое «усеченные ленты» (Lossy Timelines)?
Bluesky — это платформа с многомиллионной базой пользователей, где главная цель — быстро и эффективно доставлять контент в ленту подписчиков. Когда один человек делает новый пост, система рассылает («фэн-аутит») ссылки на этот пост всем его подписчикам, чтобы они могли видеть обновления в своих таймлайнах. Однако:
⚡ «Горячяя шарда»
Если у кого-то миллионы подписчиков, записи в базу данных начинают замедлять работу не только для этого «популярного» пользователя, но и для других, кто оказался на том же шард-сервере. Такое «накопление» нагрузки на одном сегменте (шарде) базы и называется горячая шарда (hot shard).
⚙️ Ограничения согласованности
В идеале все посты должны доходить до всех подписчиков строго последовательно и в полном объёме. Но ради спасения производительности Bluesky внедрила «теряющий» (lossy) подход: если пользователь подписан на слишком много людей, некоторая часть постов может пропускаться. Для человека, у которого в ленте обновления летят сотнями сообщений в минуту, это не критично — ведь даже «усеченная» лента будет перенасыщена контентом.
Как это устроено внутри
Автор статьи подробно рассказывает о технических нюансах, и вот как я это понимаю:
🔩 Механизм рассылки (Fanout)
- При публикации контент сначала сохраняется в основную базу данных.
- Затем система ищет всех подписчиков автора и вставляет «указатель на пост» в таймлайны этих подписчиков.
🔑 Зачем нужен фактор потерь (Loss Factor)
- У каждого пользователя есть «нормативное» число подписок (скажем, 2000).
- Если пользователь подписан на 4000 аккаунтов, то фактор потерь станет равен 0.5 — значит только половина записей действительно попадёт ему в ленту.
- Чем больше подписок, тем выше вероятность «пропуска» записи (и ниже затраты на механизм рассылки).
🗄 Redis и кэширование
- Чтобы быстро проверять, у кого больше всего подписок, нужно не долбить основную базу миллионами запросов в секунду.
- Bluesky использует Redis, подгружая список «крупных» подписчиков каждые 30 секунд. Благодаря этому система оперативно узнаёт, что у такого-то пользователя аномально высокий показатель подписок и нужно снизить приоритет при записи в его таймлайн.
Личный взгляд: почему «потери» — это не всегда плохо
Мне нравится философия «не стараться быть идеальными, если можно быть эффективными». Ведь:
✅ Большинство людей даже не заметят пропуска в ленте, когда у них настолько много источников, что посмотреть все посты физически нереально.
✅ Система остаётся стабильной, и «плохое поведение» (например, десятки тысяч подписок) не убивает производительность для других пользователей, которые находятся на той же шарде.
✅ Результаты впечатляют: по данным автора, время ответа в 99% случаев уменьшилось на 90%, а полная рассылка механизма рассылки теперь занимает не минуты, а секунды.
Из собственного опыта знаю, что поддержание сверхмасштабируемых систем часто требует компромиссов. Иначе вы упрётесь в потолок по ресурсам и столкнётесь с тем, что «одна странная» операция с огромным числом подписок будет мешать нормальной работе тысяч пользователей. В таком контексте «теряющий» подход — рациональное решение.
Любопытные детали
🔍 Горячие шарды связаны не только со «звёздами»
Иногда проблему вызывают «редкие» пользователи с массой подписок, а не обязательно знаменитость (селебрити). Политика и модерация, конечно, стараются предотвращать такие случаи, но достичь идеала удаётся редко.
🎲 Вероятностный пропуск записей
Не обязательно использовать жёсткий лимит «доставлять только каждую вторую запись». Можно гибко настраивать фактор потерь: при увеличении нагрузки на шарде доля отброшенных данных возрастает. Для крупных социальных сетей такие механизмы помогают избежать перегрузки ресурсов.
🚀 Redis vs. основная база
Решение кэшировать в Redis ещё раз показывает, что гоняться за «полной консистентностью» не всегда разумно. Да, иногда данные могут немного устареть, но это не критично для тех, у кого и так бесконечная лента.
Результат: быстрее, проще, надёжнее
После внедрения усеченных лент в Bluesky:
❤️ Система избавилась от перегрузки на «горячих» шардах.
⏱ Задержки рассылки уменьшились более чем на 90%.
⚡ Полная рассылка для миллионов подписчиков теперь занимает секунды, а не 5–10 минут.
Это отличный пример того, как сознательный отказ от «идеальности» даёт огромный выигрыш в производительности.
Для меня это напоминание: когда мы сталкиваемся с большими цифрами и масштабами, всегда нужно искать баланс между тем, что «хочется сделать по максимуму» и тем, что «достаточно хорошо для реального мира».