LinkTracker

Как это работает

Пользователь добавляет ссылку на репозиторий GitHub или вопрос Stack Overflow через Telegram-бота. Bot Service принимает команды пользователя и передаёт подписки в Scrapper Service по REST и gRPC. Scrapper по расписанию опрашивает внешние API, сравнивает состояние и публикует найденные обновления в Kafka. Оттуда их забирает слой обработки, отбирает нужное и группирует, а Bot Service читает уже готовое и отправляет пользователю. Scrapper обрабатывает ссылки батчами в нескольких параллельных задачах. Ошибка на одной ссылке не останавливает остальные и попадает в итоговый отчёт.

Если Kafka недоступна, Scrapper отправляет обновление напрямую по HTTP — маршрут другой, результат для пользователя тот же. Сообщения, которые не удалось обработать, уходят в dead letter queue, а не исчезают. Публичный REST ограничен по частоте запросов на IP, с отдельным бакетом на эндпоинт.

Устойчивость к внешним сбоям

Вся работа с чужими API обёрнута в таймауты, повторы и circuit breaker. Когда GitHub или Stack Overflow отвечают медленно или не отвечают вовсе, запросы к ним обрываются по таймауту, повторяются с задержкой, а при устойчивых ошибках цепь размыкается. Сервис перестаёт ломиться в неработающий источник и продолжает обслуживать остальные.

Отбор и группировка обновлений

Между Scrapper и ботом стоит отдельный слой обработки, тоже консьюмер Kafka. Он читает сырые обновления из одного топика, отбрасывает те, что попали под правила фильтрации, назначает остальным приоритет по ключевым словам, укорачивает слишком длинные тексты, группирует всё адресованное одному чату в коротком окне и публикует результат в другой топик. Бот читает уже готовое.

Слой намеренно детерминированный: фильтрация, приоритеты и сокращение текста — это правила, а не модель. Никакого LLM внутри нет. При этом сокращение вынесено за интерфейс, поэтому заменить правило на модель можно, не трогая сам конвейер. Код слоя ничего не импортирует из Scrapper и живёт отдельным пакетом. Чтобы вынести его в самостоятельный сервис, менять ничего не придётся.

Кеш и что он дал

Список отслеживаемых ссылок отдаётся через двухуровневый кеш: кластер Valkey из трёх узлов, а перед ним — необязательный внутрипроцессный LRU+TTL. Ключи хешируются по идентификатору чата, поэтому все страницы одного чата попадают в один слот кластера, и запись инвалидирует их одним проходом, не задевая соседей.

Нагрузочный тест прогонялся в трёх конфигурациях подряд. Это и есть ответ на вопрос, стоил ли кеш усилий:

Конфигурация	RPS	p50	p99
без кеша	146	250 мс	690 мс
Valkey	710	22 мс	250 мс
Valkey + внутрипроцессный	876	11 мс	230 мс

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

Запись при этом упирается в PostgreSQL и от кеша не ускоряется: POST и DELETE держатся в пределах 15% между вторым и третьим сценариями. Их видимое улучшение относительно первого даёт не кеш сам по себе, а то, что чтение перестало отбирать ресурсы у записи.

Наблюдаемость

Оба сервиса отдают /metrics в формате Prometheus: RED-метрики (частота запросов, доля ошибок, длительность) плюс прикладной счётчик links_on_track_total, который показывает, сколько ссылок сейчас отслеживается. Дашборды собраны в Grafana, так что состояние системы видно не по логам, а по графикам.

Тесты и сборка

Тесты идут в четыре слоя: unit, интеграционные, e2e и нагрузочные. Интеграционные поднимают настоящие Kafka, PostgreSQL и Valkey через Testcontainers, поэтому проверяется реальное поведение, а не поведение моков. Нагрузочные дали цифры, которые стоят в метриках выше. Всё это прогоняется в GitHub Actions на каждый push вместе с линтерами, сервисы упакованы в Docker.