Эти короткие, иногда очень раздражающие, но чаще почти незаметные сигналы — настоящая нервная система нашей цифровой жизни. Уведомление о том, что такси уже ждёт у подъезда, сообщение, что курьер из Лавки оставил заказ у двери, или код для входа в банковское приложение — всё это происходит благодаря им. Мы настолько привыкли к этой мгновенной связи, что даже не задумываемся, что за ней стоит.
Но что, если уведомление не придёт? Или придёт с опозданием на час, когда такси уже уехало, а пицца остыла? Что, если жизненно важный код для списания денег так и не появится на экране? Это уже не просто мелкое неудобство, а источник реальных проблем и потерянных возможностей.
Меня зовут Иннокентий Солнцев, вы слушаете подкаст «До нас дошло». Сегодня мы разберёмся, какой невидимый путь проходит обычное уведомление от далёкого сервера до вашего кармана, почему «просто отправить сообщение» — это на самом деле невероятно сложная инженерная задача, и как строятся системы, способные доставлять миллиарды таких сообщений в день практически без сбоев. А чтобы заглянуть за кулисы этого процесса, мы воспользуемся примерами и историями от инженеров из команды транспорта нотификаций инфраструктуры Яндекса, которая создала одну из самых нагруженных систем уведомлений в стране. Приготовьтесь, мы начинаем.

Прежде чем мы погрузимся в мир терабайтов и миллисекунд, давайте на минуту отмотаем время назад. Ведь потребность в надёжных уведомлениях у человечества была всегда, просто решали её совсем другими методами.
В древних городах и средневековых сёлах главным «пуш-уведомлением» был городской глашатай. Он выходил на центральную площадь и зычным голосом объявлял королевские указы, рыночные правила или последние новости. Надёжность? Зависела от громкости голоса. Скорость? Ограничивалась скоростью его ходьбы. Позже эту роль взяли на себя церковные колокола: один звон — к службе, другой, тревожный набат — сигнал об опасности. Это была уже целая система кодированных сообщений, понятных всем жителям. А для экстренной связи на больших расстояниях использовали сигнальные костры — простой, но эффективный способ передать сигнал «тревога» по цепочке на сотни километров.

С развитием государств и торговли появились и более личные уведомления. Телеграммы с их точками и тире стали первым прорывом в быстрой доставке коротких вестей. Но и бумажные письма никуда не делись. И знаете, что самое забавное? Даже сегодня в некоторых европейских странах, например, в Германии или Швейцарии, многие банки по старинке отправляют важные уведомления клиентам исключительно обычной бумажной почтой. Считается, что это официально, надёжно и защищено от цифровых взломов. Правда, о скорости здесь говорить не приходится.
Настоящая революция в мгновенных уведомлениях, конечно же, началась с появлением компьютеров. Сначала это был просто системный бип — резкий звук, сообщавший об ошибке. Но с приходом интернета всё изменилось. Миллионы людей по всему миру с замиранием сердца ждали культовую фразу «You've got mail!» от провайдера AOL, про это даже замечательный фильм сняли - рекомендую посмотреть, если еще не. А в наших краях таким звуком эпохи стал знаменитый «а-оу!» из мессенджера ICQ, который означал, что кто-то прямо сейчас хочет с тобой поговорить.
Эти первые цифровые сигналы были простыми и работали в рамках одного приложения. Но они заложили фундамент для современного мира, где уведомления должны приходить не просто быстро, а гарантированно, в любое время суток, на любое устройство и в планетарном масштабе. И это, как мы увидим дальше, задача совсем другого уровня сложности.
От ностальгических звуков ICQ мы переносимся в сегодняшний день, где масштаб уведомлений просто поражает воображение. Это уже не тысячи и даже не миллионы сообщений, а миллиарды каждый день. Только представьте: каждое ваше действие в крупном приложении — вызов такси, заказ продуктов, брошенная корзина на маркетплейсе — генерирует событие, которое должно превратиться в уведомление. А таких действий происходят миллионы в минуту.
Но главная сложность даже не в количестве, а в разнообразии каналов доставки. Ваше сообщение должно дойти, но куда?
Push-уведомление на смартфон — самый быстрый и дешёвый способ. Но он зависит от внешних гигантов: Apple, Google, Huawei, у каждого из которых свои правила, квоты и технические «капризы». Их серверы могут быть недоступны, а доставка не всегда гарантирована.
SMS-сообщение — надёжный, но дорогой канал. Идеально для кодов подтверждения, но не для каждой мелочи.
Email-письмо — хорошо для длинных сообщений и отчётов, но не для срочных уведомлений.
Звонок робота — для самых экстренных случаев, когда нужно гарантированно привлечь внимание.
Сообщение по WebSocket — для тех случаев, когда вы уже находитесь в приложении или на сайте, и нужно мгновенно обновить информацию на экране.
Инженерам, которые строят такие системы, приходится жонглировать всеми этими каналами, учитывая их стоимость, скорость и надёжность. И цена ошибки здесь очень высока. Например, если водитель такси не получит уведомление о новом заказе, он потеряет деньги, а вы — время. Если код для входа в банк не придёт, вы не сможете совершить важную операцию. А если уведомление о начале долгожданной трансляции придёт уже после её окончания, вечер будет испорчен.
Поэтому в индустрии для таких критически важных сервисов существует стандарт надёжности — «четыре девятки», или 99,99% времени доступности. На практике это означает, что сервис может быть недоступен всего несколько минут за целый год! За этой, казалось бы, простой цифрой скрывается огромная, круглосуточная работа инженеров и невероятно сложная архитектура системы, о которой мы сейчас и поговорим.
Но прежде чем мы погрузимся в детали, давайте ответим на один вопрос, который мог возникнуть у наших слушателей-разработчиков: а почему, собственно, нужна какая-то отдельная команда? Почему каждая продуктовая команда — будь то Такси, Лавка или Маркет — не может сама отправлять свои уведомления?
Изначально так и было. Например, в Яндексе система уведомлений исторически выросла из Яндекс Почты. Но по мере роста компании и количества сервисов, такой подход показал свои проблемы. Каждая команда начинала «изобретать велосипед»: писать свою логику ретраев, договариваться с SMS-шлюзами, бороться с дублями. Это приводило к дублированию кода, неконсистентному поведению и, что самое главное, отвлекало продуктовых инженеров от их основной работы.
В этот момент и происходит качественный скачок, который прошли все крупные IT-компании. Они приходят к созданию внутренней платформы — специализированного сервиса, который берёт на себя всю сложность доставки сообщений. Это классический платформенный подход, хорошо знакомый по облачным провайдерам. Например, Amazon предлагает сервис Simple Notification Service, который делает ровно то же самое. Его API для публикации сообщений стал настолько популярным и удобным, что де-факто превратился в индустриальный стандарт. Поэтому многие компании, включая Яндекс, при создании своих внутренних платформ используют совместимый с SNS формат. Это позволяет разработчикам легко переключаться между разными системами и не тратить время на изучение нового API.
Мы привыкли думать об уведомлениях как о всплывающих сообщениях на экране телефона. Но на самом деле системы нотификаций работают «под капотом» множества сервисов, обеспечивая их мгновенную и слаженную работу. Вот несколько примеров, которые помогут понять, насколько глубоко эта технология проникла в нашу цифровую жизнь.
- Обновление почты в реальном времени. Замечали, как в веб-версии Яндекс Почты новое письмо появляется на экране мгновенно, без перезагрузки страницы? Это происходит не потому, что ваш браузер постоянно «спрашивает» сервер: «Есть что-то новое?». Наоборот, это сервер сам отправляет вашему браузеру крошечное уведомление по специальному каналу WebSocket, как только приходит новое письмо. Браузер получает этот сигнал и тут же отрисовывает новую строчку. Быстро и эффективно.
- Синхронизация между устройствами. Вы установили Яндекс Браузер на компьютер и на телефон, вошли в один аккаунт и изменили закладку на одном устройстве. Через мгновение она появляется на другом. Как? Именно система нотификаций отправляет сигнал на все ваши устройства: «Внимание, настройки изменились, пора обновиться!». Это позволяет поддерживать ваши данные в актуальном состоянии, где бы вы ни находились.
- Умный дом и Алиса. Пожалуй, один из самых наглядных примеров. Вы говорите: «Алиса, включи свет на кухне». Голосовой помощник отправляет команду на сервер, тот — на вашу умную лампочку, и свет загорается. Но как приложение на вашем телефоне узнаёт, что лампочка теперь включена? Правильно, через систему нотификаций. Сервер отправляет уведомление на все ваши устройства, и статус лампочки в приложении мгновенно меняется с «выкл» на «вкл». Без этой невидимой связи магия умного дома была бы невозможна.
Эти примеры показывают, что нотификации — это не просто «дзынь» на телефоне, а фундаментальный механизм для синхронизации и обмена данными в реальном времени. Это клей, который связывает воедино разные устройства и сервисы, делая их работу быстрой, слаженной и почти волшебной.

Итак, перед инженерами стоит задача доставить миллиарды сообщений надёжно и быстро. «Просто отправить» здесь не работает. Давайте разберём несколько классических головоломок, с которыми сталкивается любая команда, создающая подобные системы.
Головоломка №1: Что, если почтальон заболел? (Гарантия доставки)

Представьте, вы отправляете пуш-уведомление, а серверы Apple или Google в этот момент на техническом обслуживании или просто перегружены. Ваше сообщение улетит в никуда. Чтобы этого не случилось, инженеры используют очереди и повторные попытки (ретраи). Сообщение не отправляется напрямую, а сначала попадает в очередь. Система пытается его доставить. Если не получилось — сообщение не удаляется, а остаётся в очереди, и через некоторое время система попробует снова.
А если и вторая попытка неудачна? Тогда в дело вступает запасной канал (fallback). Например, если push-уведомление так и не дошло, система может автоматически отправить SMS. Это дороже, но гораздо надёжнее.
Головоломка №2: Пять одинаковых сообщений (Борьба с дублями)
Бывает и обратная ситуация: из-за сбоя в сети система может решить, что сообщение не отправилось, хотя на самом деле оно уже ушло. В итоге она отправляет его ещё раз. И ещё. Так вы получаете пять одинаковых «Ваше такси приехало». Чтобы этого избежать, каждому сообщению присваивается уникальный идентификатор. Система проверяет: «А я уже отправляла сообщение с таким ID?» Если да, то все дубликаты просто игнорируются. Этот принцип называется идемпотентностью — повторение одного и того же действия не меняет результат.
Головоломка №3: Проблема «стада бизонов» (Массовое переподключение)

А теперь представьте: в целом районе на минуту пропал мобильный интернет. А потом появился. В этот самый момент десятки тысяч устройств одновременно пытаются подключиться к серверам. Или, что ещё хуже, падает один из дата-центров, и миллионы пользователей автоматически переключаются на резервный. Серверы могут просто не выдержать такого одновременного наплыва. Эту проблему инженеры называют «эффектом несущегося стада» (Thundering Herd).
И вот здесь инженеры Яндекса создали элегантное решение, позаимствовав идею из протокола TCP, на котором держится весь интернет. Они разработали систему адаптивного throttling — она не пускает всех сразу, а вводит динамические лимиты в реальном времени. Система анализирует латентность, загрузку CPU и память на каждом узле, и за миллисекунды принимает решение: увеличить поток запросов или притормозить его. Когда один из крупнейших дата-центров в Европе вышел из строя, эта система автоматически перераспределила миллионы соединений на резервные узлы, и большинство пользователей даже не заметили сбоя.
Головоломка №4: «Потерянное письмо» на iOS
Есть и совсем неочевидные проблемы. Например, по своим внутренним правилам, Apple доставляет только последнее push-уведомление, если ваш телефон был не в сети. Представьте, вам пришло три важных письма, а вы были в метро. Когда вы выйдете на поверхность, телефон покажет уведомление только о третьем, последнем письме. Первые два вы просто пропустите.
Инженеры из команды инфраструктуры нотификаций Яндека решили эту проблему, создав собственный протокол синхронизации поверх стандартных push-уведомлений, который ведёт персональную очередь для каждого устройства с версионированием сообщений. Когда iPhone появляется в сети после офлайна, происходит «рукопожатие» — устройство сообщает номер последнего полученного сообщения, а сервер в ответ отдаёт все пропущенные. Это пример того, как команда решает не только технические, но и пользовательские проблемы, создавая собственные протоколы там, где стандартные решения не работают.
И последняя, но не по значению, головоломка — это приоритеты. Согласитесь, уведомление о скидке на корм для кошек и код для подтверждения банковской операции имеют разную степень важности. Если система перегружена, чем-то придется пожертвовать, но чем?
Именно для этого нотификации делятся по приоритетам на несколько классов:
- Критические: Коды доступа, уведомления о начале поездки в такси. Они должны быть доставлены немедленно, любой ценой. Для них система использует самые быстрые каналы, агрессивные ретраи и, если нужно, мгновенный fallback на дорогой, но надёжный SMS.
- Транзакционные: важные, но задержка в несколько секунд или даже минут не критична. Такие сообщения могут немного подождать в очереди, если система занята обработкой критических уведомлений.
- Информационные: Уведомления о новых письмах, скидках или лайках. Их можно (а иногда даже желательно) доставить с небольшой задержкой, когда нагрузка на систему спадёт, или даже объединить несколько сообщений в одно, чтобы не беспокоить пользователя слишком часто.
Такая система позволяет не только обеспечить надёжность для самого важного, но и эффективно управлять ресурсами. В моменты пиковых нагрузок система может «притормаживать» наименее важные уведомления, чтобы гарантировать доставку критических.
За всеми этими сложными системами, терабайтами данных и миллионами запросов в секунду, конечно же, стоят люди — инженеры, которые каждый день решают эти головоломки. И их работа — это не просто написание кода, а целая культура мышления, направленная на создание невидимого, но несокрушимого фундамента.
Что же мотивирует этих «невидимых героев»? Прежде всего — масштаб и сложность задач. Одно дело — написать простой сервис для сотни пользователей, и совсем другое — построить систему, которая должна выдерживать нагрузку миллионов и не падать, даже если половина интернета решила одновременно заказать такси. Это игра совсем другого уровня, требующая мыслить наперёд, предсказывать проблемы и строить с огромным запасом прочности.
В конечном счёте, работа в инфраструктуре — это постоянный вызов. Как подготовиться к пиковой нагрузке на Новый год? Как найти тот самый неуловимый баг, который проявляется раз в миллион запросов? Как сделать так, чтобы система не просто работала, а была готова к росту в десятки раз в ближайшие годы? Именно решение таких задач и привлекает в эту сферу людей, которые любят строить надёжные и масштабные вещи, лежащие в основе продуктов, которыми мы все пользуемся каждый день.

Итак, за каждым простым «дзынь» на экране вашего телефона скрывается огромная, сложная и невероятно умная инфраструктура. Это целый мир из очередей, повторных попыток, динамических лимитов и хитрых обходных путей, созданный инженерами, которые одержимы одной идеей — надёжностью.
От сигнальных огней на древних башнях до мгновенных пуш-уведомлений, человечество всегда искало способ донести весть вовремя, точно и по адресу. Сегодня эту задачу решают не гонцы и не почтовые голуби, а инженеры и программисты, которые строят невидимые, но прочные мосты между сервисами и миллионами людей.
И хотя технологии стремительно меняются, главная цель остаётся прежней: сделать так, чтобы каждое важное сообщение обязательно до нас дошло.

Этот выпуск получился таким подробным и интересным благодаря инженерам из команды нотификаций инфраструктуры Яндекса, которые поделились с нами своим опытом и приоткрыли дверь в удивительный мир высоконагруженных систем. Спасибо им за это!
Вы слушали подкаст «До нас дошло». Этот выпуск для вас подготовил Иннокентий Солнцев и звукорежиссёр Алексей Попов.