Польза несовершенства на примере BlueSky BlueSky — соцсеть, созданная как альтернатива Twitter. Принцип работы тот же: пользователи создают профили, подписываются на других пользователей и видят их посты в своих лентах. Давайте посмотрим, как это работает изнутри и почему часть постов не доходит до подписчиков — и это нормально. 🔵 Таблица Timeline — те самые ленты постов — разделена на несколько шардов, где для каждого юзера выделена своя партиция. Всего на 32 млн пользователей приходится несколько сотен шардов. 🔵 Когда кто-то выкладывает новый пост, он разлетается по его подписчикам и встраивается в таблицы, из которых формируются их ленты. Одновременно старые сообщения выводятся из них.  Этот процесс работает нормально, если пользователи не шалят и не подписываются на всех подряд. Но если кто-то подписывается на тысячи или сотни тысяч аккаунтов, начинаются проблемы. 🔵 Его лента постоянно обновляется, и это создает повышенную нагрузку не только на его партицию, но и на соседей по шарду. При этом сам пользователь (если это и правда человек, а не бот) никогда не сможет прочитать все сообщения в ней. Значит, и BlueSky незачем выводить все-все новые посты — достаточно просто, чтобы в ленте регулярно появлялся новый контент. Так, чтобы избежать перегрузки, BlueSky внедрили такие понятия: 🔵 разумное ограничение (reasonable limit) на число подписок — то есть сколько подписок нужно, чтобы лента стабильно обновлялась и оставалась читабельной. 🔵 `loss_factor` — процент новых сообщений, которые не попадут в ленту пользователя. Он рассчитывается по формуле min(reasonable_limit/num_follows, 1). Допустим лимит у нас 2000, а подписан пользователь на 8000 аккаунтов. В этом случае `loss_factor` = 0,25, то есть только 25% новых постов попадут в его ленту. Внедрение таких запрограммированных потерь помогло значительно поднять производительность и снизить задержки. Как вам это решение? ❤️ — Изящно! 🌚 — Можно было и получше придумать…