Все проекты

SS7 Routing Platform

200+ стран/операторов. ~1K SMS/сек × 70 операций = 70K RPS. 99.9% uptime. 4 года в production.

70K RPS99.9% uptime200+ операторов4 года в production

Бизнес-задача

SMS-агрегатор работает с сотнями операторов по всему миру. Прямое подключение к SS7-сети дешевле, чем через SMPP-шлюзы, но требует сложной маршрутизации: выбрать оптимальный путь по цене, качеству и доступности.

Ключевая задача

SS7-протокол не позволяет отправить две SMS на один номер одновременно — вторая будет отброшена. При этом система должна держать тысячи параллельных отправок на разные номера. Решение: декомпозиция по MSISDN. Каждый номер — своя мини-очередь в Redis. Kafka распределяет нагрузку между потребителями. Один номер обрабатывается строго последовательно, разные номера — параллельно.

Архитектура

        ┌─────────────────┐
        │   API Gateway   │
        └────────┬────────┘
                 │
┌────────────────────────────────────────────────────────┐
│                           Kafka                         │
└──────┬──────────────────────────────────────┬─────────┘
       │                                      │
┌──────▼──────┐  gRPC streaming   ┌──────────────────▼───────────┐
│  sms-flow   │◀─────────────────▶│          smsc-api            │
│   (ядро)    │  bidirectional    │  (адаптер к оборудованию)    │
└──────┬──────┘                   └──────────────────────────────┘
       │                                              │
┌──────▼──────┐                   ┌──────────────────▼───────────┐
│    Redis    │                   │     SS7 Equipment            │
└─────────────┘                   └──────────────────────────────┘

Почему реактивный стек

SS7-операции (SRI, FWSM) занимают 2-16 секунд. Блокирующий ввод-вывод: 1000 параллельных запросов = 1000 потоков. WebFlux + Reactor Kafka + Reactive Redis + R2DBC решают проблему: поток отправляет запрос и переключается на другой. Обратное давление автоматически замедляет вышестоящий слой.

Почему gRPC streaming

smsc-api изолирует драйвер SS7-оборудования от бизнес-логики. HTTP запрос-ответ не подходит при ожидании 2-16 секунд. Двунаправленный стриминг: запрос уходит, соединение живёт, ответ приходит асинхронно. sms-flow может отправить 1000 запросов и получать ответы в произвольном порядке.

Стратегия TTL (Redis)

Разные данные — разное время жизни:
  • SRI-ответ (16 сек) — данные о местоположении абонента
  • FWSM-дедупликация (2-5 сек) — защита от повторной отправки
  • Справочники MCC/MNC (60 сек) — обновляются без рестарта
  • Ожидающие сообщения (72 часа) — абонент недоступен

Маршрутизация: 118 таблиц

Выбор маршрута — комбинация факторов: страна + оператор + отправитель + время суток + загрузка + история ошибок + цена. В рантайме JOIN-ов нет: конфигурация агрегируется в Redis-кэш с TTL.
  • route_map: основные правила маршрутизации
  • mcc_mnc: справочник стран/операторов (1500+ записей)
  • blacklist/whitelist: блокировки по номерам, отправителям, GT
  • ir21: данные роуминговых соглашений операторов
  • job_*: журнал состояний длительных транзакций (saga log)

Технологии

Backend

Java 17Spring BootSpring WebFluxProject ReactorR2DBCReactor KafkagRPC

Data

PostgreSQLClickHouseRedisApache KafkaLiquibase

Frontend

Vue 2VuexVue RouterChart.js

Infra

DockerDocker ComposePrometheusGrafanaGitLab CI/CD

Наша роль

  • Спроектировали реактивную архитектуру для работы с долгими сетевыми операциями
  • Спроектировали gRPC-контракты для асинхронной работы с сетевым оборудованием
  • Настроили мониторинг: Prometheus + Grafana + custom dashboards
1 слот свободен
Написать