Я в качестве хобби последний год строю собственную платформу на Clojure и DataScript. Иногда об этом рассказываю коллегам и когда меня спрашивают, зачем банку функциональное программирование и иммутабельные базы данных, я всегда отвечаю: потому, что есть кейс Nubank.
Бразильский цифровой банк Nubank за 12 лет прошёл путь от 12 клиентов до 131 миллиона, став крупнейшим цифровым банком мира за пределами Азии. Это экспериментальное доказательство того, что правильный выбор архитектуры, языка и организационной структуры может создать экономическое чудо. 131 миллион клиентов и $70 миллиардов капитализации. $2,9 миллиарда чистой прибыли за 2025 год. Рентабельность капитала (ROE) 33%. И всё это без единого физического отделения. Все данные я взял из открытых источников и в Бразилии пока не был, так что можете сами проверить.
Давайте разберём, как именно это получилось.
Пять банков, бронированные двери и ставка 450% годовых
Чтобы понять Nubank, нужно понять Бразилию. Пять банков контролировали 84% кредитного рынка. Ставка по кредитным картам достигала 450% годовых. Буквально самая высокая в мире. 34 миллиона взрослого населения не имели банковского счёта вообще. Открытие счёта занимало месяцы. Отделения были с бронированными дверями и вооружённой охраной.
В 2013 году колумбиец Давид Велез, бразильянка Кристина Жункейра и американец Эдвард Уибл решили рискнуть и не проиграли. Велез пришёл из Sequoia Capital и Stanford GSB. Жункейра пять лет проработала в Itaú и устала делать богатых людей ещё богаче. Уибл был программистом из Princeton.
Первый продукт был кредитная карта без годовой комиссии. Причём они начали не дебетовой карты как делают все банки, а доступной кредитки. Всё сделали полностью через мобильное приложение. Лимит от $10. Посевной раунд (ранняя инвестиция в стартап) $2 миллиона.
Все вокруг говорили Велезу что его раздавят, что он иностранец и не понимает Бразилию. Велез думал иначе. Он говорил, что нужно играть на рынках там где дефицит. В США переизбыток хороших предпринимателей. В Латинской Америке был значительный дефицит.
Рост оказался взрывным. 12 миллионов клиентов к 2019, и уже 48 миллионов к выходу на биржу (IPO) в декабре 2021. 100 миллионов в мае 2024. 131 миллион к концу 2025 года. 62% взрослого населения Бразилии и развитие почти полностью через сарафанное радио.
Они не выбирали язык. Они выбрали базу данных
И вот тут начинается самое интересное с технической точки зрения для тех кто строит информационные системы.
Эдвард Уибл, технический директор (CTO), сидел перед чистым листом бумаги в 2013 году. Ему были ясны три вещи. Первое, что Nubank должен достичь огромного масштаба. Затем, что главная угроза масштабу – это сложность. И нужно явно ограничить определённые категории сложности, а именно случайное мутабельное состояние в классических архитектурных стеках и закон Конвея.
Стоит объяснить почему мутабельность (изменяемость данных) это такая большая сложность.
Представьте ситуацию. Регулятор приходит и спрашивает: какой кредитный лимит был у клиента Х третьего марта в два часа дня? По какой скоринговой модели ему одобрили кредит? Какие данные были на входе модели в тот момент? В обычной базе данных лимит давно перезаписан. Модель обновлена. Входные данные изменились. Момент потерян. Чтобы ответить регулятору, нужно было заранее предусмотреть отдельное логирование. Специальные таблицы, триггеры, код для записи истории. Если не предусмотрели, данных просто нет.
Другая ситуация. Клиент оспаривает транзакцию. Нужно восстановить полную цепочку событий. Кто менял лимит. Когда менялся статус карты. Какие правила антифрода сработали и почему. Если данные мутировали, цепочку не восстановить.
Ещё одна. Модель машинного обучения (ML-модель) одобрила кредит. Через полгода клиент перестал платить. Нужно объяснить почему одобрили. Для этого нужно состояние всех данных на момент принятия решения. Если данные перезаписывались, воспроизвести контекст решения невозможно.
Это реальные ежедневные проблемы любого банка. И традиционное решение – это огромный слой дополнительной инфраструктуры. Например, таблицы аудита, журналы изменений, системы версионирования данных. Отдельные хранилища для истории. Всё это нужно проектировать, писать, поддерживать и тестировать. Тысячи строк кода которые не создают ценности для клиента, а просто необходимы для решения задач.
Теперь представьте другой подход. Данные никогда не перезаписываются. Каждое изменение – это новый факт с временной меткой. Лимит 50 000 установлен первого февраля. Лимит изменён на 100 000 пятнадцатого февраля. Скоринговая модель версии 3.2 выдала решение третьего марта на основании таких-то параметров. Все факты существуют одновременно. Нужно состояние на третье марта в два часа дня? Один запрос на третье марта 14:00. База сама покажет как выглядел мир в тот момент. Аудиторский след бесплатен. Воспроизводимость решений гарантирована. Не нужны отдельные таблицы аудита, триггеры или код для логирования.
Это и есть иммутабельность (неизменяемость). И именно это Уибл искал для банка.
Уибл прочитал классическую работу Out of the Tarpit (Из дёгтевой/смоляной ямы) авторов Бена Мозли и Питера Маркса. Работа стала культовой в инженерном сообществе: она объясняет, что главная проблема разработки больших систем — это сложность, и предлагает подход, минимизирующий состояние и контроль. Он задался вопросом, а что насчёт базы данных, которая бы всё упростила и дала бы больше за счет меньшей сложности? Этот вопрос привёл его к Datomic. Иммутабельная база данных Рича Хики. А вот Datomic привёл к выбору технологического стэка на Clojure.
На тот момент никто в команде не писал на Clojure. Но все разработчики испытывали на себе проблемы экспоненциального роста сложности любого классического стэка энтерпрайз разаботки. И долго убеждать не пришлось. Они совпали во взгляде на проблемы по словам Уибла на все сто и перешли в сторону от объектного-ориентированных языков и реляционных баз данных. Но что самое важное, что ни разу не пожалели
Почему именно Datomic? Потому что банку нужна полная история. Полный аудиторский след всего. Datomic хранит данные как иммутабельные факты в формате сущность-атрибут-значение-транзакция (Entity-Attribute-Value-Transaction). Ничего никогда не удаляется. Каждое изменение сохраняет полную историю с временными метками. Можно запросить состояние системы на любой момент в прошлом. Как Git для базы данных.
Уибл объяснял это так. Ему нужна была гибкость стартапа и функции системы записи и аудиторского следа которые есть в унаследованных (legacy) системах банков. Он не нашёл лучшего варианта чем Datomic с его первоклассной (first-class) концепцией времени.
Стек получился лаконичным до невозможности. Clojure для бэкенда. Kafka для асинхронной коммуникации. Datomic для бизнес-данных. Flutter для мобильного приложения. Облако AWS и Kubernetes для инфраструктуры.
Из инженерного блога Nubank: когда людей спрашивают о технологическом стеке, ответ довольно короткий. Они используют одни и те же немногие технологии для большинства бэкенд-систем.
Масштаб к 2025 году. Более 4000 микросервисов. 72 миллиарда событий Kafka в день. 2,5 миллиарда транзакций Datomic в день. 85+ кластеров Kubernetes. 50+ деплоев в продакшн ежедневно. Любое изменение в master может работать в продакшне через 30 минут.
В 2020 году Nubank купил Cognitect. Компанию-создателя Clojure и Datomic. Рич Хики стал сотрудником Nubank. А в 2023 они сделали Datomic бесплатным под Apache 2.0.
Вдумайтесь. Банк с капитализацией в десятки миллиардов купил компанию-создателя своего основного языка программирования. И сделал его базу данных открытой (open source). Это говорит о том насколько серьёзно они относятся к своему технологическому выбору.
Кто такой Рич Хики и почему это важно
Для тех кто не погружён в мир языков программирования, имя Рич Хики (Rich Hickey) мало что скажет. Но в индустрии он фигура уровня Линуса Торвальдса или Гвидо ван Россума. Только работает совсем в другой плоскости.
Хики провёл два с половиной года в одиночку создавая Clojure. Без инвесторов, без компании, без зарплаты. Он жил на сбережения жены. Язык вышел в 2007 году и произвёл эффект разорвавшейся бомбы в сообществе разработчиков которые устали от случайной сложности корпоративной Java.
Что сделал Хики принципиально иначе. Он не просто создал новый синтаксис. Он переосмыслил фундаментальные концепции программирования на уровне философии. Его доклады на конференциях это не технические презентации. Это лекции по эпистемологии для программистов.
Доклад Simple Made Easy (Простое и лёгкое) 2011 года стал культовым. Хики разделил два понятия которые все путают. Простое (simple) значит не переплетённое, состоящее из одной нити. Лёгкое (easy) значит привычное, близкое под рукой. Java лёгкая, но не простая. Clojure простой, но не всегда лёгкий. Хики утверждал что индустрия десятилетиями оптимизировала лёгкость в ущерб простоте. И именно поэтому софтверные проекты тонут в сложности!
Другие ключевые идеи Хики. Значения (values) важнее объектов. Время это последовательность иммутабельных фактов, а не мутирующее состояние. Идентичность это серия состояний, а не контейнер для мутаций. Информация – это факты, и факты не меняются. Дата вашего рождения не мутирует. Вчерашний курс доллара не обновляется. Старые данные не менее ценны, чем новые.
Эти идеи звучат как философия, но у них прямые инженерные следствия. Если данные иммутабельны, не нужны локи и мьютексы. Конкурентность становится тривиальной. Если база данных хранит все факты, а не только текущее состояние, то аудиторский след бесплатен. Если состояние не мутирует, тестирование становится детерминированным.
Именно эту философию Хики воплотил в Datomic. Иммутабельная база данных где время является первоклассной сущностью. Каждый факт помечен моментом его записи. Ничего не удаляется. Можно путешествовать во времени по базе данных как по Git-репозиторию.
Когда Nubank купил Cognitect, Хики стал частью банка. Человек который переосмыслил как мы думаем о данных и состоянии, теперь помогает строить финансовую систему для 131 миллиона человек. Виктор Оливейра, технический директор Nubank, сказал об этом: Рич это определяющий ум индустрии, его вклад выходит за рамки создания языка и влияет на саму природу того как должно строиться программное обеспечение.
Закон Конвея как осознанное проектное решение
Небольшая справка для тех кто не в теме.
В 1967 году программист и учёный Мелвин Конвей (Melvin Conway) отправил статью в Harvard Business Review. Редакция отклонила её как недоказанную. Статью опубликовал журнал Datamation в апреле 1968 года под названием How Do Committees Invent. Центральный тезис звучал так: организации которые проектируют системы неизбежно воспроизводят в этих системах свою собственную структуру коммуникаций.
Конвей наблюдал простую вещь. Если над компилятором работают три команды, вы получите трёхпроходный компилятор. Если интерфейс между двумя модулями проектируют две группы которые друг с другом не разговаривают, интерфейс будет неуклюжим. Структура кода зеркалирует структуру организации. Всегда.
Термин закон Конвея ввёл Фред Брукс (Fred Brooks) в легендарной книге Мифический человеко-месяц (The Mythical Man-Month) в 1975 году. С тех пор этот закон стал одним из самых цитируемых наблюдений в софтверной инженерии. Эрик Реймонд (Eric Raymond) переформулировал его так: если над проектом работают четыре группы, вы получите четырёхкомпонентный интеграционный дизайн.
Но вот что важно. Большинство компаний относятся к закону Конвея как к неизбежному злу. Мол, ну да, оргструктура влияет на архитектуру, что поделаешь. В 2015 году появилась идея обратного манёвра Конвея (Inverse Conway Maneuver). Её сформулировали Джеймс Льюис (James Lewis) и Мартин Фаулер (Martin Fowler) из ThoughtWorks. Идея проста: если вы не можете побороть закон Конвея, используйте его сознательно. Проектируйте организацию так, чтобы она порождала нужную вам архитектуру.
Именно это и сделал Nubank. С самого начала.
В блоге Building Nubank от октября 2024 года прямо сформулировано. Структура системы отражает организационную структуру которая её разрабатывает. Поэтому выравнивание технической архитектуры с организацией команд не просто полезно а необходимо.
Из этого следует несколько конкретных вещей.
Границы микросервисов совпадают с границами команд и строятся от продукта и ценности. Команды автономны и кросс-функциональны. У каждой своя долгосрочная миссия и цели с ключевыми результатами (OKR). Инженер Nubank Рафаэль Феррейра отмечал что в любой момент та или иная команда работает над разделением или слиянием сервисов. Архитектура и организация непрерывно коэволюционируют.
Примечательно что Nubank начал с микросервисов с самого первого дня. Отвергнув стандартный совет начинайте с монолита. Лукас Кавальканти, один из первых инженеров, объяснял. Они начали с идеи, и значит что либо добьются успеха, либо провалятся. Среднего результата не будет.
Они реализовали так называемый Дрейф Континентов (Continental Drift). Стратегию мульти-аккаунтов AWS где бизнес-домены и команды получают собственные AWS-аккаунты. Инфраструктурная граница зеркалирует организационную. Применение закона Конвея из учебника, но это работало!
Для меня как практика Agile и ITIL подходхов, а ещё человека который строит организационный дизайн в крупной финансовой организации, это ключевой инсайт с которым живу уже 10 лет. Команды это не ресурсы, которые назначаются на проекты. Долгоживущие продуктовые команды – это правильный организационный дизайн. Каждый раз когда вы рисуете оргструктуру – вы одновременно рисуете системную архитектуру. И наоборот.
Бел Гонсалвес, ведущий инженер (Principal Engineer) Nubank, резюмировала точно. Архитектурная структура строится не только на сервисах и платформах. Она строится на людях.
Причём тут граф
Datomic – это по сути иммутабельный граф. Каждый факт это связь между сущностью, атрибутом, значением и транзакцией. Данные никогда не перезаписываются. Для банка это означает встроенный аудиторский след без единой строчки дополнительного кода.
Nubank использует эту архитектуру в своей платформе защиты (Defense Platform). Единой системе обнаружения мошенничества которая обрабатывает около 450 миллионов событий в день с доступностью 99,98%.
Почему граф критически важен для обнаружения мошенничества (fraud detection)? Традиционные системы анализируют транзакции изолированно. Графовые модели выявляют связи. Между пользователями. Устройствами. IP-адресами. Паттернами поведения. Это позволяет находить мошеннические кольца и украденные идентификаторы используемые через множество аккаунтов. Результат. 99,2% уровень предотвращения мошенничества.
Datalog, язык запросов Datomic, поддерживает рекурсивные запросы. Что позволяет выполнять графовые обходы нативно. Но про Datalog стоит сказать отдельно, потому что это один из самых недооценённых языков в истории программирования.
Datalog. Язык которому 40 лет и который опередил своё время
Datalog появился в 1986 году как подмножество Prolog, адаптированное для работы с базами данных. Создатели Эрве Галлер (Hervé Gallaire) и Жак Минкер (Jack Minker) хотели объединить логическое программирование и реляционные базы данных. Идея была простой. Запрос к данным это логическое утверждение. А база данных это набор фактов и правил вывода. Prolog был первым языком с которого в детстве я начал изучать программирование на УКНЦ МС511 и очень его полюбил с того времени. Datalog очень похож на него.
На десятилетия Datalog остался академической диковинкой. SQL победил в коммерческом мире, Prolog ушёл в нишу искусственного интеллекта. Datalog использовали в основном для анализа программ и верификации. Скучная судьба для красивой идеи.
А потом случились графы. Ну как случились. О них просто вспомнили в энтерпрайзе. И оказалось, что Datalog решает проблемы, которые SQL решает с болью или не решает вовсе.
Первый пример. Простой запрос. Найти имена и суммы задолженности всех клиентов у которых есть кредитная карта с лимитом больше 100 000 и хотя бы одна просроченная транзакция.
На SQL это три таблицы и два JOIN:
SELECT c.name, t.amount, t.due_date
FROM customers c
JOIN cards ca ON ca.customer_id = c.id
JOIN transactions t ON t.card_id = ca.id
WHERE ca.credit_limit > 100000
AND t.status = 'overdue'Хотя всего шесть строк, но уже нужно держать в голове структуру таблиц, внешние ключи, направление связей. Добавьте ещё пару условий и пару таблиц и запрос расползается на экран.
На Datalog тот же запрос:
[:find ?name ?amount ?due-date
:where [?c :customer/name ?name]
[?c :customer/card ?ca]
[?ca :card/credit-limit ?limit]
[(> ?limit 100000)]
[?ca :card/transaction ?t]
[?t :transaction/status :overdue]
[?t :transaction/amount ?amount]
[?t :transaction/due-date ?due-date]]Никаких JOIN. Никаких внешних ключей. Вы просто описываете паттерн: есть клиент, у него есть карта, у карты есть лимит больше 100 000, у карты есть транзакция со статусом просрочена. Движок базы данных сам находит все совпадения. Каждая строка в :where это один факт, один шаг навигации по графу. Добавить новое условие значит добавить одну строку а не перестраивать весь запрос.
Но настоящая разница проявляется на втором примере. Обнаружение мошенничества. Задача: найти все устройства с которых заходили в аккаунты которые получали переводы от аккаунтов помеченных как мошеннические. По сути нужно пройти три уровня связей в графе: мошеннический аккаунт → перевод → аккаунт-получатель → устройство.
На SQL это рекурсивный CTE (общее табличное выражение) или три вложенных подзапроса. Код на 20-30 строк. Каждый уровень глубины добавляет ещё один подзапрос. Если завтра нужно четыре уровня, запрос надо переписывать.
На Datalog:
;; правило: подозрительный аккаунт (прямой или через цепочку)
[(suspicious ?a)
[?a :account/flagged true]]
[(suspicious ?a)
[?source :transfer/to ?a]
(suspicious ?source)]
;; запрос: устройства связанные с подозрительными аккаунтами
[:find ?device ?account
:where (suspicious ?account)
[?account :account/device ?device]]Восемь строк. Рекурсия встроена в саму семантику. Глубина не ограничена. Нужно четыре уровня вместо трёх? Запрос не меняется, он уже рекурсивный. И этот же запрос работает и по текущему состоянию базы, и по историческому срезу на любую дату в прошлом, потому что Datomic хранит всё.
Для банка это означает конкретные вещи. Можно моментально строить графы связей между аккаунтами и устройствами для обнаружения мошеннических колец. Можно отслеживать как распространяется подозрительная активность по сети клиентов. Можно анализировать как менялись паттерны поведения во времени. Можно не ждать задачи в бэклоге у датасаинтистов, а решить всё одним запросом.
Из исследования (case study) Cognitect: темпоральный граф показывающий эволюцию связей между клиентами и как атрибуты взаимодействуют со временем, это было элегантно решено с помощью рекурсивных запросов Datalog.
Datalog сейчас переживает ренессанс. Помимо Datomic его используют DataScript и DataHike (встраиваемые базы для Clojure и ClojureScript), XTDB (бывший Crux), Logica от Google (компилятор Datalog в SQL для BigQuery), Souffle (высокопроизводительный движок для анализа программ). Но Nubank остаётся крупнейшим коммерческим примером того что Datalog работает на масштабе миллиардов транзакций в день. Это не академическая игрушка. Это язык на котором считают деньги 131 млн. человек.
Nubank использует свыше 10 000 данных-точек на каждого клиента для собственных моделей оценки кредитоспособности. В июне 2024 они купили Hyperplane. Компанию строящую базовые модели для финансовых данных. Модели обрабатывают триллионы транзакций. Система Precog анализирует все действия пользователя в приложении как язык, предсказывая намерения клиента.
Велез заявил что их видение стать компанией с приоритетом ИИ (AI-first), встраивающей базовые модели во все продукты.
$0,80 против $5. Экономика которая изменила правила
Вот цифры которые объясняют всё.
Стоимость обслуживания одного клиента у Nubank. $0,80 в месяц. Около $10 в год. У традиционных бразильских банков. $5+ в месяц. $60 в год. Разница 85%.
Стоимость привлечения клиента (CAC). $5-7. У американского необанка Chime исторически больше $100. 90% новых клиентов Nubank приходят через рекомендации друзей.
Коэффициент эффективности (efficiency ratio). 19,9% у Nubank против 45-50% у традиционных банков. Это означает что Nubank тратит в 2-2,5 раза меньше на операции для генерации каждого доллара дохода.
Рентабельность капитала (ROE) 33% против 22,7% у Itaú и 12,4% у Bradesco.
Индекс потребительской лояльности (NPS) 87-92 против среднего 36 у традиционных банков. Почти в три раза выше.
11 000 сотрудников обслуживают 131 миллион клиентов. У традиционных банков около 100 000 сотрудников обслуживают сопоставимое число. Разница в эффективности в 10-20 раз.
Клиенты Nubank сэкономили в совокупности $20,5 миллиарда на банковских комиссиях и 440 миллионов часов которые они провели бы в очередях.
Велез объяснял просто. Если бы за три года до этого он захотел запустить банк, ему бы понадобилось $50 миллионов на мейнфрейм IBM. С миллионом долларов они смогли запустить первые кредитные карты полностью в облаке.
Что это значит для РФ и стран СНГ
Я часто слышу от коллег в российских банках. Зачем вам этот Clojure. Зачем иммутабельные базы. Зачем графы. Возьмите нормальную C#, Java и Posgres, где то Camunda, и не усложняйте.
Nubank – это ответ. Это не академический эксперимент. Это доказательство на масштабе 131 миллиона клиентов и $70 миллиардов капитализации.
Три ключевых урока
Первый. Выбор технологического стека это не техническое решение. Это стратегическое. Иммутабельная база данных и функциональный язык это механизм снижения сложности который окупается миллиардами.
Второй. Закон Конвея это не наблюдение, а инструмент проектирования. Каждый раз когда вы строите оргструктуру вы одновременно проектируете архитектуру. Делайте это осознанно.
Третий. Самый недооценённый технологический рычаг это стоимость обслуживания (cost-to-serve). Когда обслуживание клиента стоит $0,80 вместо $5, вы можете обслуживать людей которых традиционные банки считали невыгодными. И построить на этом компанию мирового масштаба.
Главный урок Nubank не в Clojure и не в Datomic. Он в том что технология, организация и экономика – это единая система. И проектировать их нужно вместе.Nubank начинал с чистого листа бумаги. Мы не всегда можем себе это позволить. Но мы точно можем перестать думать о технологиях, организации и бизнесе как о трёх разных вещах.
p.s. Следующая статья будет про то какой выигрыш даёт datalog и темпоральная графовая БД для AI-агентов.
Автор: ProgressorIncrementum
