События переходов отправляйте в ограниченный асинхронный поток, а не выполняйте тяжёлую аналитику внутри redirect. Политику потерь при отказе очереди задайте явно.
Внедрение модуля сбора аналитики
События переходов отправляйте в ограниченный асинхронный поток, а не выполняйте тяжёлую аналитику внутри redirect. Политику потерь при отказе очереди задайте явно.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
Условие
Сервис обрабатывает поток GET‑запросов через API Gateway → TinyUrl GET → Cache/DB. Необходимо расширить архитектуру компонентой, отвечающей за сбор аналитики. Требуется реализовать фиксирование данных о переходах по ссылке:
- Что фиксировать: short_link, timestamp, IP, user‑agent, referer и прочее.
- Куда направлять события: в отдельный поток, базу данных или логгер.
- Как гарантировать, что сбор аналитики не будет тормозить основной GET‑поток.
- Какие инструменты применять: очередь (Kafka/PubSub), асинхронный воркер, батч‑обработку.
- Как построить хранение и агрегацию аналитических данных (например, ClickHouse).
Ответ
События переходов отправляйте в ограниченный асинхронный поток, а не выполняйте тяжёлую аналитику внутри redirect. Политику потерь при отказе очереди задайте явно.
Событие содержит event_id, short_code и время; user-agent, referer и IP собирают только в необходимом объёме с ограничением доступа и сроков хранения. Referer может содержать чувствительные query-параметры, их нельзя бездумно сохранять целиком.
Воркеры пакетно пишут в аналитическое хранилище и строят агрегаты по ссылке и времени. Повторную доставку одного события дедуплицируют по event_id. Ограниченный буфер защищает память: при переполнении выбирают допустимый сброс либо устойчивый журнал. Нельзя одновременно обещать нулевую задержку, отсутствие потерь и бесконечную недоступность очереди. Мониторят lag и потерянные события.