Мы считаем, что Ruby отлично подходит для описания бизнес-логики финансовых сервисов. Пример тому — стартапы вроде Stripe, GoCardless, Gusto. Мы же с его помощью помогли финтех-компании «Рево Технологии» выйти из оффлайна в онлайн.
«Рево» пришли к нам, технически, с MVP версией своего приложения. Мы помогли им с большим количеством задач (в том числе и с выводом продукта на европейский рынок), но сегодня хотим ответить на достаточно холиварное «почему».
Почему мы поделили монолит финансового продукта на микросервисы?
До нашего прихода над продуктом успели поработать несколько подрядчиков. Не спешите кидаться помидорами — это совершенно нормальная ситуация на этапе запуска и проверки основных гипотез. В это время важно запустить фичи и быстро получить обратную связь, поэтому иногда основатели решают не стелить себе соломки на будущее (не тратить слишком много времени на архитектуру, например), а получить прирост в скорости.
Так вот бизнес-логика продукта была прописана в разрозненных js-файлах на клиентской части. Побочным эффектом этого стало то, что одна и та же функция могла быть прописана совершенно по разному в нескольких местах одновременно.
А уже из-за этого страница загружались дольше, у некоторых пользователей функции могли просто не работать. Не говоря уже о том, что поддержка была головной болью. ЦБ опубликовал новые ставки? Будь добр, залезь во все файлы, где она задействована.
Мы распутали клубок: в отдельные микросервисы отделили личный кабинет и модуль выдачи, финансовые расчёты переехали на бэкенд, все API свели воедино.
Теперь новые функции реализуются легче, старые тоже достаточно просто исправляются, если это необходимо (порой даже в легаси лезть не надо), а всякие рутинные мелочи вообще делаются на раз-два.
После истории с изменением архитектуры нас ждали другие интересные задачи: новый личный кабинет, интеграция розничных сетей и магазинов — об этом можно подробнее узнать в кейсе на нашем сайте. А про отделение европейской версии продукта мы расскажем отдельно.