Отвечая на ваш вопрос - "не медленее". Потому что ваш скрипт по-хорошему не стучиться на вашу авторизацию от имени сервера. Клиентское приложение (яваскриптовое) стучиться на ваше апи, делает это в асинхронном варианте, то есть несколько запросов одновременно, где возможно. И ваш сервер с приложением, где раньше была синхронная авторизация от того, что часть нагрузки ушла на другой сервер только вздохнет с облегчением.
Поэтому желание сначала "всё сделать так", а потом "всё сделать наоборот" - неверное.
Верно сделать монолит, а потом те части которые постоянно в деле - вынести на другую машину с этим самым апи. Авторизацию, социальный модуль (это тот который друзья друзей друзей друзей по графу постоянно рассчитывает), можно платежку тоже отдельно, чтобы ожидания меньше были. Не надо делать ВСЁ отдельно, чтобы оптимизировать.
Сначала всё пишется в "синхронном коде", по мере того как появляется код который должен быть выполнен строго после того как бизнеслогика отработала, т.к. несет за собой последствия, которые потом надо откатывать - появляется "асинхронный код", который представляет собой обыкновенный while (true) в конце когда и кучу \Closure в виде цепочек (то есть они выполняются не в глубь, а в ширину 10 очередей - 10 функций одна за другой, шаг while (true), осталось 5 очередей (5 завершилось) - теперь 5 функций одна за другой, которые ставятся в очередь, используя promise (да, в пхп тоже так можно, причем если вы используете \React\Promise библиотеку, то вы получите обход вглубь, но это неверно, и ведет к нарушению порядка выполнения действий, нужно сначала десять первых уровней, потом десять вторых, тогда как промиз сделает для вас 1-2-3-4-5, следующий 1-2-3-4-5, смысл в том, что третий из первого может хотеть второй из второго например).
Когда даже это начинает глючить - куски приложения выбрасываются в другие приложения, а в своем коде внутри всовывают как вы пишете - внутри контроллера вызов апи через хттп, где возможно - с кешированием. То есть на авторизацию запроса не делается, а вот если вам нужно к примеру получить кучу заказов, то вызов апи будет примерно "добавить заказ", а потом где-то на второй машине работает фоновая программа, которая "ждет что вы добавите заказ" и как только добавился - он обрабатывается.
Потом это где-нибудь падает в стиле "всё работает, но результат неверный" и вам нужно отслеживать, кто что сделал, и тогда появляется уже некая система "кто что когда запустил и когда об этом отчитался". То есть ваш заказ из прошлого абзаца это была новая задача "обработать заказ", которая появилась в результате той задачи что вы ставили "добавить заказ". И вот только когда первая выполнилась, поставив вторую, потом выполнилась вторая - тот второй сервер шлет первому уведомление, что задача готова, или ничего не шлет (если база данных общая - и после перезагрузки страницы изменения будут видны)
Таким образом старая добрая система пишем монолит, копируем весь код на три машины, меняем конфиг роутера, чтобы работал только кусок - прекрасно работает для всех приложений уровнем до фейсбука.
Худшее, что вас ждет - это создание диспетчера фоновых воркеров. Это такая хрень, которая очень напоминает пхпшную функцию debug_backtrace() только вы реализуете её сами из тех задач которые делаются по апи. То есть вы не делаете запрос "http GET", вы ставите задачу "http POST" (запись в лог, событие), через какое-то время задача стартанула (запись в лог, событие), задача выполнена (запись в лог, событие), задача провалилась (запись в лог, событие), и так для каждой задачи, а задачи по сути ещё одна другую могут запускать.
То есть это не обязательно стоит делать для авторизации, которая должна быстро отрабатывать, но когда начинают играться с "много серверов" творят именно такую чернуху.
В принципе есть написанные штуки вроде даже приемлемого качества типа Temporal (хотя они предлагают организацию именно фоновых запусков приложений, а не фоновых приказов десятку машин), написанный командой Spiral. У Spiral не лучший код в мире, но качество уровня симфони они дать могут.
Средний
Средний
