Платформа телеметрии фронтенда в реальном времени

Проблема

Часть пользователей молча бросала длинный многошаговый сценарий. Когда ломалась интеграция со сторонним сервисом, никто этого не видел: диагностика сводилась к ручному разбору разрозненных серверных логов и занимала дни. Каждый такой день — это реальные пользователи, которые не смогли завершить процесс.

Подход

• Небольшой типизированный SDK. Один трекер на TypeScript собирал одни и те же данные о действиях пользователя на каждом экране и платформе, поэтому событие означало одно и то же везде.
• Ограничение частоты с предохранительным клапаном. SDK группирует события и отправляет их по короткому таймеру или по достижении лимита размера — что наступит раньше. Один запрос на клик истощает сетевые потоки браузера; держать события дольше — риск потерять их при закрытии вкладки, поэтому при выгрузке страницы используется navigator.sendBeacon.
• BFF, который проверяет данные. Пакеты попадают в Backend for Frontend: он сверяет схему с определениями TypeScript, проверяет правдоподобность временных меток, удаляет неожиданные поля и персональные данные и добавляет метаданные сессии. Сравнение вердикта бэкенда с тем, что показывал интерфейс, выявило расхождения состояний между ними.
• Потоковый конвейер в колоночное хранилище. Потоковая обработка сглаживает всплески трафика, а колоночное хранилище отвечает на агрегации по очень большим наборам событий с высокой кардинальностью за миллисекунды, где строковые хранилища еле ползут.
• Тихая обработка сбоев. Если конвейер недоступен, SDK держит небольшой буфер локально, а пассивный предохранитель приостанавливает отправку. Он не опрашивает сервер, чтобы проверить его состояние, а ждёт следующего успешного ответа.

Результат

Время обнаружения инцидента сократилось с дней до менее чем 5 минут. Когда сломанный шаг означает множество неудачных попыток, это разница между строчкой в постмортеме и исправлением в то же утро.