Алексей Траньков

Частные микроинвесторы финансируют малый и средний бизнес и еженедельно получают фиксированный купон плюс долю от роста выручки заёмщика. Деньги физлиц ходят через номинальный счёт банка-партнёра: платформа ими не владеет, а распоряжается по поручению. Это значит, что каждая операция — реальные чужие деньги под надзором ЦБ, и «потом починим» не существует как опция.

Примеры того, что построено внутри:

• Свой клиент к API номинальных счетов Т-Банка. Декларативные Action-классы вместо россыпи HTTP-вызовов: бизнес-код читается как обычные функции, знание банковского API инкапсулировано. Идемпотентность вынесена на уровень экземпляра запроса, для предотвращения гонки POST-запросов.
• Приём денег: терминальный эквайринг и СБП. Подпись запросов токеном, вебхуки, рекуррентные платежи, покупка доли с внутреннего кошелька (отложенная оплата).
• PROD, STAGE и DEV на одном номинальном счёте. Код окружения зашит в идентификатор заказа, вебхуки и фоновые задачи фильтруют чужие транзакции. Тестировать деньгами на живом счёте — и не поломать живые деньги.
• Сверка с банком и разбор инцидентов. Нераспознанные входящие, холды против реальных остатков на виртуальных счетах, зависшие выплаты. Собран отдельный набор процедур: как найти недофинансированного депонента, почему банковская валидация сделки возвращает «всё ок» и всё равно врёт. Внедрены AI-инструменты для внутреннего разбора инцидентов.
• Авторизация через Госуслуги (ЕСИА). КриптоПро, ГОСТ Р 34.10-2012, ключ на физическом Рутокене, отдельный сервис-подписант. Подпись через изолированные файлы в tmpfs с уникальными именами — потому что готовые Python-обёртки над КриптоПро работают нестабильно.
• Справочник БИК напрямую из ED807 ЦБ РФ. Свой парсер формата УФЭБС и индекс в памяти: поиск банка по БИК — микросекунда, 100 КБ вместо 950 КБ XML.
• Портирование библиотек из других языков. Например, библиотека для определения типа банковской карты по номеру (JS → Python).
• Ускорение на компилируемых языках. Модули на Rust (PyO3 + maturin) для маскировки чувствительных данных в URL, JSON и документах — с неповторяющимся кодированием, чтобы усложнить реверс. Nim — для обработки логов. Оба заменяемы на чистый Python drop-in, чтобы не привязывать заказчика к редким компетенциям.
• Проверка контрагентов и документов: Dadata, Контур, распознавание документов через Dbrain, СМС и Telegram-уведомления.
• Три собственных MCP-сервера для отладки прода — доступ к API номинальных счетов, Redis и логам прямо из ИИ-агента (+ self-hosted Sentry, у которого свой MCP). Разбор денежного инцидента вместо нескольких часов ручных запросов занимает несколько минут.

Работающий продукт: 360°-туры и аудиогиды по достопримечательностям, поверх которых слой коммерции — бронирование и оплата отелей, ресторанов и экскурсий, доставка, трансферы, бонусный кошелёк. Около двадцати Django-приложений в одном бэкенде, две версии API.

• Бронирование как отдельное ядро. Разные типы объектов — отели, рестораны, экскурсии — со своими сценариями, собранными из общих миксинов. Интеграция с гостиничной системой TravelLine: контент, наличие, резервирование.
• Платежи через ЮKassa и бонусный кошелёк со списанием и начислением баллов при бронировании.
• ИИ-поиск на собственной LLM. Qwen на MLX-сервере, поднятом на своём железе, доступ по приватной сети — без внешних API и без утечки пользовательских запросов наружу. Конвейер из трёх шагов: категоризация запроса → определение локации → поиск по признакам, специфичным для категории. Промпты хранятся в базе и правятся без релиза, с фолбэком на зашитые в код.
• Единый контракт для фронтенда. Результаты ИИ-поиска приводятся к той же схеме, что и обычный поиск: фронт не знает, каким путём пришёл ответ, и не содержит двух веток обработки.
• Единая обработка ошибок API: доменные исключения отображаются в HTTP-коды централизованно, ответ всегда одной формы.

Бэкенд мобильного приложения, разнесённый на четыре независимых FastAPI-сервиса: авторизация, профили и семейные пространства, лента воспоминаний, хранилище медиа. Каждый — свой контейнер, своя база, свой пайплайн в GitLab CI.

• Полностью асинхронный стек: FastAPI, Tortoise ORM, asyncpg, uvloop. Межсервисное взаимодействие — через тонкие клиенты-«аутлеты», а не общую базу.
• Вход через Google и Apple, push-уведомления через Firebase, сессии с устройствами и правами.
• Медиа в S3 с транскодингом видео в HLS и проверкой загружаемых файлов.
• Материализованные представления PostgreSQL для тяжёлых выборок профилей — управляются из кода вместе с миграциями.
• Собственная библиотека асинхронных свойств с кэшированием и ленивой подгрузкой связей: убирает лишние обращения к базе в async-моделях. Покрыта тестами, включая гонки и наследование.
• Отдельный пакет smoke-тестов, гоняющий живой API по сценариям через все четыре сервиса.

Извлечение значений из глубоко вложенных структур Python одним выражением: ключи, атрибуты и индексы вперемешку, без каскада проверок и try/except. Путь объявляется один раз и переиспользуется — когда контракт внешнего API меняется, правится одна строка в декларациях, а не двадцать мест в коде. Единственный код, который я могу показать публично: клиентские репозитории закрыты.