WebSocket у Vercel и живые запросы Neon. Когда данным нужна секунда, а когда хватит минуты

В октябре сразу несколько платформ объявили о работе в реальном времени. Vercel вывел WebSocket в своих функциях из беты, Neon сделал живые SQL-запросы, Stripe начал сам складывать платежи в Postgres у Supabase и Neon, а Netflix рассказал, как перестроил конвейер рекламных событий под прямые эфиры. Для владельца бизнеса за этим стоит один вопрос: какие данные в компании должны обновляться за секунду, каким хватит минуты, а каким ночной выгрузки. От ответа зависит, сколько стоит система и в скольких местах она может встать.

Что вышло и у кого

Vercel 20 октября написал в changelog, что поддержка WebSocket в Vercel Functions стала общедоступной. С запуска публичной беты в конце июня их CDN обслужил 300 миллионов соединений, сейчас это 15 миллионов в день. Соединения тарифицируются как обычные вызовы функций, а при тарифе Active CPU процессорное время считается только пока обрабатывается сообщение.

В блоге Neon 15 октября вышла короткая заметка о том, что Neon Realtime доступен в публичной бете: любой SQL-запрос можно сделать живым, подписаться на него, и результат будет обновляться по мере изменения данных, без опроса.

Supabase 15 октября описал, как Stripe Data Pipeline синхронизирует данные Stripe в Supabase. Подключение делается из панели Stripe. Stripe загружает историю, потом держит данные в актуальном состоянии: платежи, возвраты, споры, клиенты, подписки и счета приходят таблицами в отдельную схему с префиксом stripe_sdp. Stripe подключается отдельной ролью с доступом только к этой схеме и по короткоживущим токенам, без пароля базы. Neon 16 октября сообщил то же самое про свой Postgres: подключение из панели Stripe и живые данные о платежах рядом с данными приложения.

Netflix 14 октября опубликовал вторую часть рассказа о конвейере рекламных событий. Раньше рекламный сервер при каждом показе синхронно записывал метаданные в глобальный реестр и ждал подтверждения. Для прямых эфиров это не годилось: бой Джейка Пола с Майком Тайсоном смотрели больше 100 миллионов зрителей, и один рекламный блок означал бы миллионы обязательных записей в базу в секунду на критическом пути. Инженеры Netflix заменили запись в базу потоковым соединением в Apache Flink: сервер логирует, что показал, а сопоставление с событиями от устройств идёт после. Отказ хранилища больше не останавливает показ.

Пример: прокат, у которого три скорости данных

Возьмём компанию по аренде автомобилей. Менеджер на выдаче смотрит, свободна ли машина и какие у неё фото с осмотра. Ему нужно состояние на сейчас: если две брони на одну машину разойдутся на минуту, клиент будет ждать на стойке. Бухгалтер сверяет платежи за вчера, и ему хватит утренней выгрузки. Табло с загрузкой парка в офисе может отставать на минуту, никто не заметит.

Если все потоки гнать через WebSocket, вы платите за соединения ради табло, которому хватило бы запроса раз в минуту. Если все складывать ночью, менеджер на выдаче будет звонить коллеге и спрашивать, не взял ли кто машину. У Netflix та же задача в другом масштабе: каждый обязательный синхронный шаг на пути к клиенту нужно обосновать.

Как я выбираю канал

В PDR-компании в США, с которой я работаю с 2021 года, TV-карточки на 4 телевизорах обновляются в реальном времени: собственник, производство, фронт-деск и продавцы видят загрузку и движение заказов. Звонок на IVR сразу создаёт лид в CRM, потому что опоздание здесь стоит клиента. А суперапп для продавцов построен offline first: на выезде продавец делает фото и ведёт лида без связи, и приложение синхронизирует данные, когда связь появится.

Для консалтинговой компании в Лондоне в 2023 году я делал Scraper Hub, сервис сбора новостей со 120 источников. Ход сбора показывался в интерфейсе через WebSockets, потому что человек запускал сбор и ждал результата. В программе расчёта заказов для производственной компании сервер и клиент тоже связаны по WebSocket: расчёт идёт в среднем 65 секунд, и конструктор видит, что происходит.

А в сервисе «Кофе вместе» каталог поставщика синхронизируется по расписанию, до трёх запусков в неделю. Сумма заказа появляется после того, как организатор сверит настоящую корзину. Здесь секунда никому не нужна, а постоянное соединение с API поставщика добавило бы мест, где всё может сломаться. WebSocket у Vercel, живые запросы Neon и конвейер Stripe я у себя не проверял и сужу по их описаниям.

Что я бы сделал

Выписать потоки данных в компании и для каждого назвать цену опоздания на минуту и на час.

Для секундных потоков брать WebSocket или живой запрос, но с резервом: при обрыве соединения клиент запрашивает полное состояние заново.

Для минутных потоков делать фоновый воркер с повторами и защитой от двойной обработки.

Внешние сервисы убирать с критического пути. Если платёжная система или CRM легла, выдача машины продолжается, а данные дойдут позже.

Считать цену: на платформе вы платите за соединения как за вызовы функций, на своём сервере они стоят памяти и внимания к лимитам.

Фоновые задачи и повторы я разбирал в статье о воркерах и в обзоре о повторной обработке без повторного результата. Проекты из этого обзора: PDR-компания, Scraper Hub и расчёт заказов для производства. Про телевизоры и leaderboard есть обзор о метриках, которые учат команду плохим решениям, про цену платформ обзор о бэкендах на Vercel, Fly и Supabase, про наблюдаемость на одном сервере этот. Направления: внутренние системы и API-интеграции. Если у вас есть данные, которые должны обновляться быстрее, чем сейчас, расскажите, какие и зачем. Обсудить задачу.