architecture-insuretech

Сдача проектной работы 8 спринта

На этот раз вы выступите в роли архитектора ПО для InsureTech. Компания предоставляет агрегационные услуги в сфере
страхования. Она работает с частными и корпоративными клиентами:

• частным клиентам компания предлагает удобный сайт для подбора и оформления страховок,
• корпоративным клиентам и партнёрам предоставляет API для интеграции страховых услуг в их продукты.

Сейчас основной продукт InsureTech — это страхование жизни.

Проблемы компании

Компания успешно запустила MVP своего приложения и планирует активно развиваться дальше. Всё бы хорошо, но приложение
столкнулось со всеми классическими проблемами быстрого роста:

• Сайт медленно загружает страницы. Когда нагрузка на приложение повышается, пользователи массово жалуются на то,
  что страницы грузятся по несколько минут или не загружаются вообще. При этом максимально зафиксированная нагрузка
  на запросы поиска составила 50 RPS, а на запросы оформления — 10 RPS. Такое положение дел плохо влияет на показатели
  NPS и retention.
• Нарушается SLA для B2B-клиентов. Менеджеры уже неоднократно получали сообщения от партнёров, что SLA API не
  соответствует заявленному. В ходе изучения таких инцидентов выяснилось, что в эти периоды количество запросов от
  одного из партнёров кратно возрастало. Оно достигало суммарно 250 RPS на все вызываемые операции. По сути, один из
  партнёров «сжирал» все ресурсы приложения. С этим партнёром изначально договорились, что нагрузка не будет превышать 20 RPS.
• Приложение падает. InsureTech несколько раз столкнулась с проблемой недоступности приложения. Команда реагировала на
  проблему очень медленно, поскольку узнавала о ней от пользователей. Каждый час простоя сервис несёт финансовые
  убытки — примерно 500 тысяч рублей. Также бизнес несёт репутационные потери: в СМИ выходят негативные публикации, у
  сервиса низкие показатели удовлетворённости пользователей, а некоторые партнёры уже заявили о нежелании продлевать сотрудничество.

InureTech планирует в ближайшее время провести большую рекламную кампанию. Ожидается существенный прирост пользователей.

Вам как архитектору нужно проработать описанные проблемы и предложить для них решения. В текущем состоянии приложение
является «узким горлышком» для развития бизнеса.

Архитектура приложения

Основные компоненты приложения:

• core-app — монолитное бэкенд-приложение. Оно отвечает за отображение доступных клиенту продуктов, оформление заявок
  на новые страховки и отображение уже оформленных.
• client-info — сервис управления клиентскими данными. Он передаёт данные core-app для оформления страховок. Если
  пользователя нет в базе данных или его данные изменились, в процессе оформления страховки сервис client-info вносит
  данные в базу. Он же отвечает за отображение и редактирование клиентских данных в личном кабинете.
• ins-product-aggregator — сервис интеграции со страховыми компаниями для получения информации о продуктах. Ещё он
  запрашивает у разных партнёров предложения по ОСАГО для конкретного автомобиля. Сервис предоставляет единый API,
  агрегируя данные от всех страховых компаний.
• ins-comp-settlement — сервис взаиморасчётов со страховыми компаниями. Раз в месяц он отправляет перечень оформленных
  страховок в страховые компании для расчёта выплаты агентских премий.
• Веб-приложение для клиентов сервиса.

Для деплоя всех приложений используется кластер Kubernetes, расположенный в одной зоне доступности.

В качестве базы данных используется PostgreSQL. Каждый сервис, использующий БД, имеет отдельную схему данных. БД
развёрнута на отдельной ВМ в единственном экземпляре.

Взаимодействие между фронтендом и бэкендом происходит посредством REST.

API предоставляет партнёрам доступ напрямую через LoadBalancer Kubernetes, который доступен в сети Интернет.

Бэкенд-приложение интегрировано с пятью страховыми компаниями.

Вот диаграмма контейнеров приложения в модели C4: