В этой статье я поделюсь откровениями и расскажу о реальном кейсе, который стал самым масштабным вызовом в моей карьере системного архитектора, аналитика, разработчика и технического директора.
Осенью 2019 года я задумался о переезде с семьёй на постоянное место жительства в Чехию. Мы уже были там в 2012 году, и нам понравилось. Но особенно привлекала возможность иметь двойное гражданство, в отличие от большинства стран Европы: можно сохранить своё родное гражданство и спустя 10 лет законного проживания получить чешское.
Однако для запроса вида на жительство (ВНЖ) в любой стране Евросоюза необходимо основание. Нельзя просто приехать и сказать: "Я хочу здесь жить, дайте мне ВНЖ". Основанием может быть учёба (не актуально для меня), бизнес (драконовские налоги и обязательство нанимать нескольких граждан Чехии), брак (я уже счастливо женат более 15 лет) или работа (вот это уже вариант).
В Чехии многие сайты, в отличие от других стран, имеют русскоязычные версии, и я подал несколько заявок на работу. На одном из собеседований познакомился с Дмитрием – владельцем микрофинансовой организации. У него была необычная проблема: он использовал софт нескольких разработчиков, каждый из которых дополнял работу другого, но у всех не хватало чего-то важного.
На тот момент я работал в компании, разрабатывавшей платформу peer-to-peer кредитования с оборотом 40 млн. евро и 30 тыс. инвесторов. До этого я был разработчиком и тимлидом в микрофинансовой организации. Опыт в финтехе у меня уже был, и масштаб задач был понятен.
Мы долго обсуждали с Дмитрием, каким должен быть продукт. В итоге оффер трансформировался в партнёрство: пока я не переехал в Чехию, я разрабатывал новый софт, а Дмитрий показывал лучшие практики существующих решений. После переезда я планировал работать у него и параллельно продавать этот софт другим компаниям. Он должен был получиться действительно крутым.
Прошло несколько месяцев, и на Новый 2020 год мы с семьёй полетели в Прагу. Новогоднее фото с Праги ниже. Я лично встретился с Дмитрием, вдохновился перспективами и вернулся домой готовиться.
А затем началась пандемия... Границы закрылись, все страны ввели кредитные каникулы, бизнес Дмитрия встал на паузу, заёмщики прекратили выплаты, текущий работодатель в виде платформы peer-to-peer кредитования обанкротился, кредитные организации потеряли доход, сотрудников сократили – так я оказался на бирже труда.
В мае 2020 года мне написали люди, которым меня порекомендовали как эксперта. Они уже два года разрабатывали свою платформу, но подрядчики постоянно кормили их обещаниями "ещё чуть-чуть, вот-вот". Меня попросили оценить ситуацию.
Когда я заглянул в код, пришёл в ужас. Это был даже не легаси-код, а просто фасад с мусорным исходником внутри. Я написал отчёт, объяснил, что всё плохо, и спросил, как они до такого дошли. Оказалось, сначала проект разрабатывала одна команда, потом вторая, и обе убеждали, что всё отлично.
На очной встрече с заказчиками и разработчиками я попросил показать, какие пункты договора выполнены. Выяснилось, что реализовано не более 20%, а остальное – муляж. После долгих споров технический руководитель подрядчика признал: "Михаил прав".
Через неделю заказчики обратились ко мне с просьбой: "Миш, спасай ситуацию. Сроки вышли, инвестор может подать в суд, денег осталось мало, а нам надо выйти в продакшн". Я отказался дорабатывать чужой код и предложил следующее: взять мои разработки для микрофинансовой организации и адаптировать их под краудфандинговую платформу. Но при этом оставить софт в формате White Label, чтобы я мог продавать его другим клиентам.
Мне понадобилось три летних месяца, чтобы довести свои наработки до полностью рабочей краудфандинговой платформы. Было страшновато: денег платили столько же, сколько моя зарплата на прошлой работе, но нанять кого-то не хватало, поэтому всё лежало на мне – проектирование, микросервисная архитектура, фронт, бэкенд, базы данных. Главное, чего я боялся, – не справиться и подвести людей.
Я справился, и в сентябре 2020 года платформа была готова к запуску. Теперь я хочу порадовать айтишников, рассказав о деталях архитектуры, а затем вернусь к повествованию.
Архитектура получилась нестандартной. Конечно, я знал о монолитных и микросервисных решениях, но ни один из этих вариантов мне не подходил. Монолитная архитектура была бы плохо масштабируема и в итоге превратилась бы в спагетти-код, где всё связано со всем. Хуже решения и не придумаешь. Но и полноценная микросервисная архитектура требовала слишком много ресурсов: для каждого сервиса пришлось бы настраивать деплой, контейнеры и прочее. Это ловушка, но делать что-то было необходимо.
Я принял необычное решение. Первым делом я разработал сайт платформы на Laravel. Это был просто промо-сайт, доступный неавторизованным пользователям, с единственной интеграцией через API для отображения списка доступных проектов. Преимущество такого подхода было в том, что дизайнер заказчика мог вносить любые изменения в оформление, не рискуя сломать что-то важное.
Обычно в Laravel и PHP-среде клиентский кабинет размещают прямо на основном сайте платформы: пользователь авторизуется и тут же может пополнять баланс, делать инвестиции и так далее. Именно так мы работали в платформе peer-to-peer кредитования, но это решение усложняло код, увеличивало связанность компонентов и в конечном итоге превращало проект в громоздкий монолит, который потом невозможно было бы декомпозировать. Поэтому я сделал отдельный субдомен my и вынес туда ещё один сайт на Laravel. Этот сайт требовал авторизации, имел свой дизайн и позволял пользователям пополнять баланс, проходить процедуру KYC (знай своего клиента), инвестировать, отслеживать транзакции и баланс, выводить средства и использовать реферальную программу.
Бэк-офис для управления платформой я также сразу решил сделать отдельным субдоменом. Мы использовали такой подход в платформе peer-to-peer кредитования, и даже при наличии команды и финансирования это было технологически сложным решением. В моём случае я работал в одиночку, с ограниченными сроками и финансами. Поэтому я продумал ряд оптимизаций и в итоге создал оптимальный и функциональный бэк-офис, которым горжусь до сих пор.
Но это было ещё не всё. Я понимал, что система будет постоянно меняться: появятся новые требования, обновятся версии PHP и Laravel. Оказаться в ловушке роста, когда три монолита работают с одной базой данных, мне не хотелось. Поэтому я создал "единый источник правды" — API-сервер на отдельном субдомене apis, работающий на Laravel. Сначала я рассматривал возможность использовать Lumen (облегчённую версию Laravel для API-интерфейсов) или Slim, но в итоге отказался от него по ряду причин.
После этого клиентский кабинет и бэк-офис оставили за собой только базы данных для авторизации. Все остальные данные они получали через API-сервер. Это оказалось "золотым" решением — не в плане дороговизны, а с точки зрения возможностей. Самое главное, что теперь я мог кэшировать данные: когда обновлялась информация в базе, сбрасывался только соответствующий кэш, что обеспечивало высокую скорость работы API.
Но и это ещё не всё. Я разделил API-сервер на несколько слабо связанных модулей: банкинг, инвестиции, KYC и другие. При этом в самих модулях осталась только бизнес-логика и работа с базой данных и кэшем, а все интеграции с внешними системами я вынес в отдельные микросервисы-адаптеры. Каждый такой микросервис-адаптер отвечал за взаимодействие с конкретным внешним сервисом.
Например, модуль KYC в apis не зависел от конкретного провайдера проверки клиентов. Он просто передавал и получал данные от соответствующего адаптера. В моём случае таким провайдером был SumSub — удобная система с виджетом, который встраивался в клиентский кабинет на последнем этапе процедуры KYC. Она принимала документы, проверяла их по 10 000+ базам, выявляла фальшивые и просроченные документы, сверяла фото с видео и подтверждала личность пользователя. Все данные автоматически сохранялись в базе.
Если бы заказчик вдруг захотел заменить SumSub на Veriff или другой сервис, мне нужно было бы просто переписать один микросервис. Если адаптер уже был готов, его можно было просто подключить. Более того, можно было использовать сразу несколько сервисов для разных юрисдикций. Например, один провайдер мог бы обслуживать клиентов из Европы, а другой — из Азии. Всё это легко сочеталось, не требуя глобальных изменений в коде.
В платёжном микросервисе я изначально реализовал интеграцию с Paysera, но понимал, что в будущем могут понадобиться другие платёжные системы. Поэтому заложил поддержку мультивалютности. Например, в платформе peer-to-peer кредитования я подключил пять разных платёжных провайдеров всего за полгода, когда работал там.
Инвестиционный модуль в apis использовал стандартную логику подобных сервисов, но поддерживал гибкие графики платежей с возможностью их пересчёта и редактирования. Самая сложная проблема, с которой я столкнулся, — расчёт дробных центов. Это критический момент, способный привести к расхождению балансов на тысячи долларов, даже если система кажется работающей корректно. Это целая научная задача, но я нашёл точное и логичное решение.
Был также модуль генерации документов из шаблонов, которыми можно было управлять через бэк-офис. Можно было заранее установить дату вступления шаблона в силу, что позволяло автоматически менять версии документов без ручного вмешательства. Например, до 1 января использовался один договор, а с 1 января автоматически вступал в силу новый, без необходимости менять код.
Я также разработал мощный модуль ведения исторических данных по любым сущностям: клиентам, проектам, инвестициям, финансовым операциям. Это позволяло видеть, кто и когда вносил изменения, на каком основании, с какого IP-адреса. Причём эта база данных работала только на запись: существующие данные нельзя было удалить или изменить. Это был своеобразный "чёрный ящик", аналогичный тем, что используются в авиации, что позволяло вести независимое расследование любых инцидентов.
Заказчик был несказанно рад, что за три месяца его "задница была спасена" проблемы остались позади. Они написали мне благодарственный отзыв и подписали акты приёмки. Но впереди ждал новый вызов. В ноябре Евросоюз принял новую директиву, согласно которой в течение года все краудфандинговые платформы ЕС должны были получить краудфандинговую лицензию и соответствовать новым требованиям.
Мы начали изучать регламент и ужаснулись. Самые сложные изменения касались работы с деньгами и банковского модуля. Раньше все средства хранились на одном номинальном счёте компании, и платформа самостоятельно учитывала, кому и сколько принадлежало. Теперь фактически вводилась автоматизированная банковская система (АБС), но в виде API от внешнего сервис-провайдера.
Как объяснить масштаб проблемы? Представьте: раньше мы полностью полагались на собственные данные, принимали и отправляли деньги. Когда внутри платформы кто-то кому-то что-то переводил, физически средства не двигались — они оставались на номинальном счёте платформы в банке, а мы просто обновляли записи в нашей базе, фиксируя изменения балансов.
Новое законодательство всё меняло. Теперь внешняя служба управляла деньгами клиентов, и средства зачислялись непосредственно в этот внешний платёжный сервис-провайдер. В нашем случае это должен был быть LemonWay — сервис от французского банка. Краудфандинговая платформа теперь становилась торговым агентом, а не хранителем средств. Для каждого клиента в LemonWay автоматически создавался индивидуальный банковский счёт с привязанным к нему виртуальным IBAN (банковским счётом), а также процессингом банковских карт. Клиенты перечисляли деньги на свои виртуальные IBAN-аккаунты, но дальше уже не имели прямого управления средствами.
Платформа в этом процессе играла роль манипулятора — как в игровых автоматах с механической рукой, которая достаёт игрушки (если повезёт). Она только "перекладывала" деньги с одного счёта на другой. Такие же индивидуальные счета создавались для заёмщиков, которые собирали финансирование на свои проекты, а также для самой платформы, куда поступали комиссионные с инвестиций.
Но это были только цветочки… Новое регулирование вводило множество новых регламентов, усложняло процедуру KYC, добавляло массу новых требований.
В итоге заказчик решил не спешить со стартом. Он сначала хотел привести платформу в соответствие с новым регулированием, а уже потом выходить в production. Мы выполнили все необходимые преобразования, клиент подал заявку на получение лицензии… но регулятор на тот момент ещё никому их не выдавал. Более того, сами регуляторы до конца не понимали, как именно оценивать соответствие, правила постоянно менялись, процесс затягивался, шли бесконечные "качели" и доработки. А потом инвестор заказчика прекратил финансирование проекта — и карета превратилась в тыкву.
Клиент как бы остался, но его как будто и нет. А денег от него теперь ждать не приходилось.
Поскольку нужно было принимать деньги от клиента, а в какой-то момент я находился на бирже труда, я открыл юридическое лицо и стал получать деньги от клиента на него.
Я создал сайт по адресу FinMV.com (домен короче, чем у Google.com). Потом так вошел в кураж, что перевел его на 36 языков, перевел на различные языки все демо, сделал демо-версию платформы и организовал отличное SEO-продвижение. Лиды пошли, много лидов. Я лично общался с каждым русскоязычным клиентом. И вот, я сделал еще одну продажу. Создал платформу в качестве краудинвестинговой (немного отличающейся от краудфандинговой) для Казахстана. Мне понадобилось пару месяцев на кастомизацию (индивидуальный дизайн и настройки), затем я добавил еще несколько языков, благо платформа была мультиязычной. Ребята были хорошие, они обещали взять меня на роль CTO (технический директор). Я был на всех совещаниях как партнер, ходил на созвоны к регулятору и писал все ответы на его технические вопросы, помогал чем мог, но платить мне уже не хотели. Говорили, как Медведев: "Денег нет, но вы держитесь". Кассовый разрыв стал нарастать, и мне пришлось вернуться в корпоративный сектор. Ребята из Казахстана в прошлом году получили официально краудфандиновую лицензию и вышли в production с моим исходным кодом, моя ценность для них уменьшилась, и они уже не планировали взять меня на борт. О чем они думают, я не знаю, на совещаниях не был уже год, потому что меня туда не звали.
Лиды с сайта поступали все это время, по 2-3 в день. Я пытался собирать различные команды для продаж. В одной из них был Дмитрий из Чехии, о котором я писал ранее. Мы несколько раз были близки к успешной продаже, но что-то всегда шло не так. Всё-таки я не продажник, да и разговорный английский у меня не на высоте. А больше половины лидов были на английском языке.
Вы можете посмотреть видео-демо платформы на любом из 36 языков: английский (en), испанский (es), русский (ru), немецкий (de), французский (fr), итальянский (it), китайский (zh), японский (ja), португальский (pt), хинди (hi), арабский (ar), бенгальский (bn), корейский (ko), турецкий (tr), ирландский (ga), болгарский (bg), голландский (nl), польский (pl), венгерский (hu), греческий (el), датский (da), норвежский (no), шведский (sv), финский (fi), литовский (lt), латвийский (lv), эстонский (et), чешский (cs), словацкий (sk), словенский (sl), румынский (ro), хорватский (hr), иврит (he), индонезийский (id), вьетнамский (vi), малайский (ms). Зацените, как я говорю по-арабски, по-китайски или по-японски!
Этот софт я использую в своих многочисленных проектах, и с его помощью мне удаётся творить настоящие чудеса. Он был изначально разработан так, чтобы быть максимально универсальным. Нужен онлайн-банк? Нет проблем! Требуется платёжная система, ERP, CRM, складская программа, система кадрового учёта, агрегатор, или что-то совершенно другое… В общем, всё, что только можно вообразить!
На данный момент я использую этот софт в White Label сети маркетинговых агентств. Суть проста: для каждого партнёра-блогера создаётся отдельное маркетинговое агентство. Блогер привлекает трафик, и все лиды аккуратно собираются в единой системе через мой софт. "Под капотом" этой системы - пул исполнителей, которые, благодаря автоматизации, быстро отчитываются о результатах своей работы и получают оплату за труд. Это позволяет создавать эффективные, масштабируемые проекты с минимальными затратами времени и усилий, при этом каждый партнёр может быть уверенным в прозрачности и точности всей работы.
Нужен эксперт для проекта или помощь по вашему направлению? Я готов обсудить возможность сотрудничества
Профессиональная помощь по внедрению микросервисных архитектур и высоконагруженных систем