Архитектура FinTech приложения: монолит vs микросервисы для MVP

Архитектура fintech приложения — тема, которая определяет успех IT-проекта. Стартап пришёл к нам после полугода работы с другой командой. Они хотели сделать «всё правильно» с самого начала — выбрали архитектуру FinTech приложения по образцу Netflix: 12 микросервисов, Kubernetes, service mesh. Через 6 месяцев у них не было ни одного пользователя в продакшне. Только инфраструктура, которая стоила $3 000 в месяц и требовала DevOps-инженера на полный день.

Мы слышим эту историю регулярно. И каждый раз говорим одно и то же: правильная архитектура FinTech приложения для MVP — это почти всегда монолит. Не микросервисы. Не «как у Netflix». Модульный, хорошо организованный монолит.

Это звучит контринтуитивно. Поэтому давайте разберём детально.

Почему все хотят микросервисы — и почему они ошибаются

Рассмотрим, как архитектура fintech приложения работает на практике.

Микросервисы стали символом «серьёзной» разработки. Если ты строишь архитектуру FinTech приложения на микросервисах — ты профессионал. Монолит — это стыдно, это «легаси», это «технический долг».

Этот миф стоит стартапам месяцев и миллионов рублей.

Откуда он взялся? Из историй успеха. Netflix, Uber, Amazon — все они перешли на микросервисы. Только никто не рассказывает, что они это сделали, когда у них уже было несколько миллионов пользователей и сотни инженеров. Netflix начинал как монолит. Uber начинал как монолит. Amazon начинал как монолит.

Микросервисы решают проблемы масштабирования. У вас на стадии MVP нет этих проблем. У вас есть другие проблемы: скорость разработки, стоимость изменений, debugging под давлением.

Монолит для FinTech MVP: реальные преимущества

Почему архитектура FinTech приложения должна быть монолитной на старте? Вот конкретные причины, которые важны именно для финансовых продуктов:

Транзакционность — критично для FinTech

В финансовых приложениях атомарность операций — это не опция, это требование. Если перевод денег состоит из нескольких шагов (дебит одного счёта, кредит другого, запись в audit log, уведомление), все они должны быть выполнены или откатиться вместе.

В монолите с одной PostgreSQL это тривиально: один SQL-transaction. В микросервисах это превращается в распределённую транзакцию с saga pattern, compensating transactions и возможностью partial failure. Для стартапа это неоправданная сложность.

Скорость разработки

Мы запускаем FinTech MVP за 22 рабочих дня. Это возможно только с монолитом. В микросервисной архитектуре к этому добавляются: настройка service discovery, межсервисная аутентификация, API gateway, distributed tracing, мониторинг каждого сервиса отдельно. Это легко ещё 2-3 недели только на инфраструктуру.

Debugging и observability

Когда баг в продакшне — в монолите один стек трейс. В микросервисах нужно трейсить запрос через 5 сервисов с разными логами в разных местах. На стадии MVP, когда вы ещё изучаете поведение пользователей, это существенное замедление.

Стоимость инфраструктуры

Монолит на Yandex Cloud: один сервер, одна PostgreSQL, один Redis — $100-200 в месяц для типичного MVP. Kubernetes с 5+ микросервисами: минимум $800-1 200 в месяц только за инфраструктуру. И это не считая DevOps-инженера.

Когда микросервисы действительно нужны в FinTech

Вопрос архитектура fintech приложения заслуживает детального анализа.

Это не статья против микросервисов. Это статья про правильное время для правильной архитектуры FinTech приложения.

Переходить на микросервисы стоит тогда, когда:

• Команда разработки > 5 человек — тогда разные команды могут деплоить независимо
• Чётко выделены домены с разными требованиями к нагрузке — например, payment processing требует 99.99% uptime, а notifcation service — нет
• Регуляторные требования диктуют изоляцию — например, PCI DSS требует отдельной зоны для cardholder data
• Разные части системы пишутся на разных языках — это бывает при поглощениях или специализированных AI-компонентах
• Нагрузка действительно неравномерна — один компонент нужно масштабировать отдельно от остальных

Типичный FinTech стартап на seed достигает этих порогов примерно при 50 000-100 000 активных пользователей или при найме 8-10 инженеров. До этого момента монолит справляется.

Правильная архитектура FinTech MVP — наш подход

Именно архитектура fintech приложения определяет результат для бизнеса.

В IT2BE мы выработали стандартную архитектуру FinTech приложения для MVP, которая позволяет быстро запуститься и не создаёт проблем при масштабировании.

Ядро: модульный монолит с Domain-Driven Design

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

Типичная структура для FinTech MVP:

• auth/ — аутентификация, JWT, refresh tokens
• accounts/ — управление счетами пользователей
• payments/ — транзакции, переводы, история
• kyc/ — верификация, документы, статусы
• notifications/ — email, push, SMS
• audit/ — неизменяемый лог всех операций

Стек: FastAPI + PostgreSQL + Redis

FastAPI даёт async из коробки, автоматическую OpenAPI документацию и хорошую производительность. PostgreSQL — ACID-транзакции, JSON-поля для гибкости, row-level security для многопользовательских сценариев. Redis — кеш, session storage, rate limiting.

Единственное исключение: compliance/audit service

Для ФЗ-152 и KYC/AML требований мы выносим audit log в отдельный сервис с append-only хранилищем. Это не столько микросервис по архитектурным причинам, сколько регуляторное требование: audit trail должен быть физически изолирован и защищён от модификации основным приложением.

Event-driven где нужно: Kafka или RabbitMQ

Асинхронные события — для уведомлений, фоновой обработки, интеграций с внешними сервисами. Для MVP обычно хватает RabbitMQ. Kafka — если с первого дня нужна гарантированная доставка и retention сообщений (например, для финансовых операций с внешними шлюзами).

Как масштабировать монолит без переписывания

При правильном подходе архитектура fintech приложения становится конкурентным преимуществом.

Самый частый страх фаундеров: «Мы напишем монолит, а потом его придётся переписывать». Это миф, если монолит написан правильно.

Путь масштабирования архитектуры FinTech приложения выглядит так:

1. Горизонтальный монолит — несколько инстансов одного приложения за load balancer. Решает большинство проблем с нагрузкой до 50 000-100 000 пользователей. PostgreSQL + read replicas. Никакого переписывания.
2. Extract hot paths — если конкретный домен создаёт bottleneck, выносим его в отдельный сервис. При правильном DDD это занимает недели, не месяцы. Первым обычно выносится payment processing.
3. Database per service — только когда реально нужна независимость масштабирования. Это последний шаг, не первый.

Ключевое условие успешного масштабирования: с первого дня писать бизнес-логику без прямых зависимостей между доменами. Если домен payments импортирует модели из домена kyc напрямую — разделить потом будет болезненно. Если взаимодействие только через события и публичные API — extract в отдельный сервис это рефакторинг, а не переписывание.

Если сейчас выбираете архитектуру для FinTech или EdTech MVP — приходите на консультацию. За 60 минут разберём вашу предметную область, определим правильную структуру доменов и скажем, нужны ли вам какие-то нестандартные решения для вашего конкретного продукта.