В теории если ты пишешь обе стороны которые должны общаться, то ты можешь передавать информацию как тебе удобно или как сам придумаешь. Можно складывать файликами в папочки "входящие-исходящие", отправлять через сокеты, просто записывать в память и передавать другому сервису адрес, отправлять по сети, или через брокеры сообщений.
В реальности, граздо чаще нужно сконнектить твой софт (твой бек) с каким-то чужим, в исходники которого ты не хочешь (не можешь) лезть, чтобы добавить ему какой-то новый "протокол общения". Или даже нужно сконнектить несколько "чужих" сервисов. Например базу данных, каие-то обработчики, нотификаторы, логгеры, и т.д.
И тогда ты не можешь выбирать из всего спектра возможностей существующего в природе, а выбираешь как их коннектить исходя из списка того, что эти сервисы поддерживают. И выбираешь по каким-то своим критериям. Для начала, по производительности, например.
А потом приходит начальник, и говорит. - эээ, мы вообще планировали распараллеливать эту нейронку, у нас будет от 10 до 10500 инстансов в в облаке. Данные давайте сложим вот в монго-кластер, задачи по обработке сбрасываем в очередь в celery, если очередь вырастает больше чем на N, то кубер автоматически поднимает еще несколько инстансов... и так далее, насколько у него фантазия разгуляется.
И когда у тебя сервисы крутятся не на одном компе, то всякая производительная экзотика, типа общей памяти - отпадает. Остается сеть, очередь, REST. И ты выбираешь не то что популярно на хабре в этом году, а сравниваешь что вообще умеют те сервисы, которые ты хочешь получить. Возможно делаешь несколько вариантов и сравниваешь по той-же производиительности. Возможно добавляешь какие-то дополнительные прослойки-обертки-посредники конвертирующие запросы, уменьшая при этом производительность, ага. :)
И как-то так получается, что пока у тебя маленький проект на одном сервере - тебе эти накладные расходы "со всем издержками http протокола" погоды не делают. А когда компов много, то может так выйти, что кроме этого протокола и альтернатив не так уж много.
А кроме производительности бывают вопросы типа "сервис упал во время работы, что случилось с задачей которую он обрабатывал? Нужно ли его рестартнуть? Нужно ли перебросить эту задачу на другой инстанс? Если все таски работают нормально, а эта уже в пятый раз упала, то может она кривая какая-то?" И тут понеслось новым слоем - система мониторинга, оповещения, автоматический или полуавтоматический "кризис менеджмент".
В общем тема большая, и большие коммпании решают ее по разному - структура сервисов фейсбука и алиэкспресса может сильно отличаться, и каждый будет уверен что его подход хорош. Ну или не очень хорош, но менять архитектуру для сотени или тысяч сервисов - дорого. И комания binance основанная 5 лет назад может архитектурно оказаться гораздо современнее и технологичнее какого-нибудь paypal'а основанного в прошлом тысячелетии. И не потому что paypal не шарит, а потому что переделывать большую систему очень дорого.
А в майкрософте, основанном 50 лет назад, можно вообще очень странные и неэффективные штуки найти, я уверен.
В общем, о чем это я - тема сложная, и одного решения на все случаи нет, и быть не может.
В большинстве случаев оценивать нужно не только накладные расходы, но и масштабируемость, отказоустойчивость, насколько легко это все поддерживать, и цену, конечно-же. И цену за лицензии и зарплаты людей, которые это внедняют и обслуживают.
Простой
