Где живут данные: MongoDB, ClickHouse, Postgres

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

MongoDB — источник правды

Основное хранилище ядра: транзакции, мерчанты, счета, гейты, банки, балансировщики, списки и лог взаимодействия с гейтами. Пока данных о платеже нет здесь — платежа для системы не существует, независимо от того, что показывают остальные две базы.

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

Как данные попадают в остальные две базы

ClickHouse и Postgres billing не получают запись напрямую — их наполняет один общий конвейер, отдельный от очередей платёжного пути. Ядро создаёт и меняет документ в MongoDB, изменение подхватывается через механизм Change Streams, уходит в Kafka и оттуда разбирается двумя независимыми обработчиками — один кладёт данные в ClickHouse, другой в Postgres.

Важное следствие: это не та Kafka, о которой говорится в очередях платёжного пути — там Kafka осознанно не используется, платёж не ждёт эту репликацию ни на одном шаге. Конвейер работает асинхронно и с отставанием, поэтому если платёж уже виден в MongoDB через API, но ещё не появился в ClickHouse или в Postgres — это нормальная задержка репликации, а не потеря данных.

ClickHouse — аналитика

Не операционная база и не источник правды: сюда никто не ходит, чтобы принять решение по конкретному платежу. Здесь строятся дашборды мерчанта, отчёты по конверсии и другая аналитика, для которой важна скорость агрегирующих запросов по большому объёму транзакций, а не мгновенная актуальность одной записи.

Postgres billing — зеркало для отчётности

Тем же конвейером данные попадают в Postgres, где они лежат готовыми представлениями для биллинга и начислений. Как устроен сам биллинг — отдельная тема, которая пока не описана, см. Биллинг.

Кто переносит данные из Kafka и где это работает

Три процесса на pm2, у каждого своя роль и свой сервер:

Процесс	Что делает	Репозиторий	Сервер (EC2)
mongo2mq	Читает Change Streams MongoDB, публикует в Kafka	mongo2mq/index.js	mongo2mq-extractor-server (ip-10-0-3-158.eu-central-1.compute.internal)
mq2postgres	Разбирает Kafka, пишет в Postgres billing	mq2postgres/index.js	mongo2mq-extractor-server (ip-10-0-3-158.eu-central-1.compute.internal)
mq2clickhouse	Разбирает Kafka, пишет в ClickHouse	mq2clickhouse/index.js	clickhouse-server (ip-10-0-2-182.eu-central-1.compute.internal) — тот же хост, что и сама база

Оба сервера доступны только через bastion. Если конвейер отстаёт сильнее обычного или совсем встал — смотреть логи pm2 нужно на одном из этих двух хостов, в зависимости от того, какая база не получает данных.

Как подключиться руками

Прямого доступа снаружи ни к одной из трёх баз нет — везде bastion.

• MongoDB — Atlas, доступ через VPN без bastion; клиент — Studio 3T.
• ClickHouse и Postgres billing — доступ через SSH-туннель на bastion (18.199.118.114) персональной учётной записью, дальше клиент — DBeaver. Учётка в bastion и в самой базе — не одно и то же: сначала пробрасывается порт через SSH, а на другом его конце уже спрашивают логин и пароль в саму базу.

Практическое правило

При разборе конкретного платежа источник ответа — всегда API ядра, то есть MongoDB, а не аналитические базы. ClickHouse и Postgres billing полезны для вопросов вида «сколько» и «как менялось со временем», а не «что сейчас происходит с этой транзакцией».

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

Куда дальше

• Статусы и стадии транзакции — что именно лежит в документе транзакции в MongoDB.
• Баланс, комиссии, финализация — откуда берутся цифры, которые в итоге попадают в биллинг.
• Биллинг — пока не написана.