Нагрузка на REST API в описанной реализации?

Question

[Иван Воробей]

Цель
Реализовать API с единым аккаунтом и локальными профилями. Подобие TM у Хабра.

Проблема
Не хватает опыта оценить "костыльность" решения. Нет цели провести синтетические тесты на нагрузку, хотелось бы увидеть что-то вроде "норм ахитектура, не загоняйся" или "быстро вырастет нагрузка, нужно переделать"

Описание архитектуры
А - авторизационный API. Здесь храним аккаунты, связанные соц сети, email ну и все что положено.
Для конкретики расположим его в
api.company.com/

P - проект. Он связан с Account API. Регистрироваться в проекте не нужно, аккаунт уже заведен на api.company.com. Расположим проект тут:
api.project.com/

C - клиент. Любой сайт, мобильное приложение (и т.д.), работающее с API Project.

Взаимодействие
Реализовано в лучших традициях: JWT, http статусы (200, 201 и т.д.), канал https, get/post/delete.. и прочее, за что любители православного REST-а не закидают тухлыми камнями :)

цифры на картинке совпадают с нумерацией ниже

- Авторизация:
1 - Пользователю отображается форма входа. Логин-пароль отправляются в заголовке запроса, запрос направляется к API Project. Что-то вроде:
api.project.com/login... c Authorization заголовком.
2 - API Project не хранит данные аккаунта, и делает запрос к API Account, передавая тот же заголовок. Ждет ответ.
3 - API Account проверяет логин-пароль, и если все в порядке, генерирует JWT. Возвращает его API Project.
4 - API Project возвращает токен клиенту. Так как запрос удался (токен был возвращен, хотя и не может быть расшифрован) - создается в проекте локальный профиль. Он связан с аккаунтом.

- Обычный запрос:
Так как токен получен (описал выше), то можно отправлять запросы. Картинка подойдет та же.
1 - Клиент отправляет на API Project запрос, прикрепляя в заголовке токен.
2 - API Project не знает как расшифровать токен. Отправляет запрос с токеном на API Account. В свою очередь API Account может расшифровать JWT, и проверяет его.
3 - Токен проверен, API Account возвращает ID пользователя, которому принадлежит токен. API Project теперь понимает для какого пользователя выполнить запрос. Выполняет и..
4 - Отправляет ответ клиенту.

Для дочитавших до конца, дублирую вопросы:
Критично ли вырастет задержка?
Если да, как лучше организовать систему с один аккаунтом?

P.S. Речь не SSO, вопрос конкретно о взаимодействии по API.

Спасибо со слезами на глазах!

Answer 1

[Defman21]

Выглядит вполне нормально. Можно, конечно, обращаться к АПИ аккаунтов напрямую, передавая уникальный ID проекта, а уже само АПИ аккаунтов будет генерировать уникальный токен, который будет понятен только проекту, который запрашивает конечный пользователь, но как по мне - это делает всю систему немного запутаннее.

Comments

[Defman21]

Кстати, похоже, что сервисы ТМ используют второй метод (передают ID проекта серверу авторизации и генерируют уникальный токен для проекта). Делайте так, как Вам будет удобнее.

[Иван Воробей]

Defman21: думаю я остановлюсь на варианте попроще.
Как считаете, то что каждый запрос к API Проекта будет делать запрос к API авторизации не сильно нагрузит сервер?
Сегодня сделал тестовую систему, на холодную 300ms было, дальше в районе 100ms

[Defman21]

Иван Воробей: 100ms - это не очень много, как по мне.
Посмотрите в сторону CAS: https://en.wikipedia.org/wiki/Central_Authenticati... Не пугайтесь, что это SSO, это то, что Вам нужно.

[Иван Воробей]

Defman21: смотрел, то что нужно. Но фраемворки работают на сессиях и сделаны под WEB. А мне для API. Реализовывать свой CAS... вот и придумал систему, описанную в вопросе.