Skip to main content
Architecture14 min read

Создание финтех-платформы в одиночку: 185 таблиц, 69 API, 7 систем

Полная история архитектуры и создания экосистемы Nexural с нуля — проектирование базы данных, архитектура API, интеграция Stripe и уроки работы единственным инженером на продакшн-финтех-платформе.

Part ofFintech & Trading Systems->
By Jason TeixeiraApril 20, 2026
Next.jsSupabaseStripeArchitectureDatabase DesignFinTech
Share:
On this page

Большинство инженеров работают над одним сервисом за раз. Я построил целую экосистему.

Платформа Nexural начиналась как простая идея: дашборд для моего трейдерского сообщества. Она превратилась в полноценную финтех-платформу с 185 таблицами базы данных, 69 API-эндпоинтами, биллингом Stripe, AI-ботом для Discord, исследовательским движком, студией рассылок и системой оповещений в реальном времени.

Я спроектировал и построил всё это. Вот что я узнал.

Связанная система: Build a product surface and system map превращает тот же паттерн «поверхность/система» в повторяемый фреймворк для разработчика.

Объём работ

Семь взаимосвязанных систем:

  1. Торговый дашборд — рыночные данные в реальном времени, графики, отслеживание портфеля
  2. AI-движок Discord — 30+ команд, интеграция GPT-4o, автоматическая модерация
  3. Исследовательский движок — 71+ метрика, анализ стратегий, импорт CSV
  4. Система оповещений — интеграция с NinjaTrader 8, бэкенд на .NET, уведомления в реальном времени
  5. Студия рассылок — автоматическая генерация и рассылка контента
  6. Трекер стратегий — мониторинг производительности торговых систем
  7. Пакет автоматизации — 61 тестовый набор, CI/CD, контроль качества

Проектирование базы данных в масштабе

185 таблиц звучит пугающе. Ключом стало поэтапное проектирование:

  • Этап 1 (Ядро): Пользователи, аутентификация, подписки — 20 таблиц
  • Этап 2 (Торговля): Инструменты, позиции, сигналы — 35 таблиц
  • Этап 3 (Сообщество): Интеграция Discord, логи модерации — 25 таблиц
  • Этап 4 (Аналитика): Метрики, отчёты, телеметрия — 30 таблиц
  • Этапы 5–7: Исследования, оповещения, рассылки — 75 таблиц

У каждого этапа были своя миграция, свой набор тестов и свой план отката. Я никогда не изменял более одного домена за раз.

Решения по схеме, которые имели значение

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

Денормализация там, где важна скорость: Торговые дашборды запрашивают денормализованные представления. Трейдеру всё равно на 3НФ — ему важна скорость загрузки менее 50 мс.

Безопасность на уровне строк везде: Политики RLS Supabase на каждой таблице. Пользователь никогда не увидит данные другого пользователя, даже если в API есть ошибка.

Архитектура API

69 эндпоинтов, следующих единым паттернам:

Reader route

article -> proof -> offer

ReadClusterProofScope

cluster

Fintech & Trading Systems

intent

Architecture

route

next step

What to do with this

Turn the note into a build path.

If this topic maps to a real business problem, keep reading the cluster, study the academy path, or route the work into a scoped engagement.

Jason Teixeira
Written by
Jason Teixeira
Founder, Sage Ideas Studio · Principal Engineer
livebuild 81e8c8e2026-07-28 06:02Z
// solo studio// no analytics resold// every commit human-reviewed