Архитектура12 мин чтения

Архитектура доверия в Финтехе

Как мы строим безопасные, соответствующие требованиям и надёжные финансовые системы, используя событийно-ориентированную архитектуру.

Автор: Лев Данилов, основатель и технический директор

В финтехе «доверие» — не маркетинговый слоган, а свойство системы: каждая операция должна быть воспроизводима, каждый доступ — проверяем, каждый сбой — изолирован. Мы опираемся на event-driven архитектуру не ради моды, а потому что она естественно даёт аудит, идемпотентность и независимое масштабирование критичных контуров.

Слои ответственности

Выделяем четыре контура: API-шлюз с аутентификацией и rate limiting, доменные сервисы (платежи, балансы, KYC), шина событий с гарантией доставки и read-модели для отчётности. Прямых синхронных вызовов между доменами по возможности нет — только через контракты событий и saga для распределённых транзакций.

Если нельзя восстановить цепочку «кто, когда и почему изменил баланс» — архитектура не готова к продакшену.

Идемпотентность и дедупликация

Каждый входящий запрос на списание несёт idempotency-key. Обработчик сначала пишет intent в outbox, затем публикует событие PaymentInitiated. Повторная доставка не создаёт вторую операцию — ключ хранится в хранилище с TTL и уникальным индексом.

Compliance без паралича

Требования 152-ФЗ, PCI DSS или отраслевые регламенты не должны появляться в коде «в последний день». Закладываем маскирование PII в логах, шифрование at rest для чувствительных полей и ролевую модель с principle of least privilege с первого спринта. Аудит-лог — отдельный append-only поток, не таблица в основной БД.

Такая архитектура дороже на старте, но дешевле при росте: новые продукты подключаются как подписчики на события, а не как очередной «монолитный модуль», который ломает всё остальное.

Понравился подход?

Давайте обсудим, как применить эти практики в вашем проекте.

Начать обсуждение
Архитектура доверия в Финтехе — BIVEKI