Приступим к асинхронности. Она, конечно же, скрывает много подводных камней, которые мы и начнем поднимать со дна :)
Асинхронные системы давно стали модным архитектурным выбором. «Поставим Rabbit/Kafka — и всё взлетит» звучит примерно как «перепишем на микросервисы — и станет быстрее» 😆😆😆.
На практике же асинхронность — это не инструмент, а архитектурное мировоззрение, которое меняет буквально всё: от того, как устроена модель данных, до того, как работает команда разработки и как взаимодействуют с системой пользователи.

Недавно поймала себя на мысли, что мне очень нравится делать разборы в формате развенчивания мифов (часть из которых и были моим мнением, пока я не стала копать). Ниже — разбор основных иллюзий, с которыми сталкиваются команды, делая первые шаги в сторону асинхронности.

🪝 Скрытая синхронность: RPC поверх брокера и его ловушки

Первая ошибка, в которую попадают команды: пытаясь уйти от синхронного REST, они переносят те же паттерны поверх брокера сообщений. Возникают решения вида RPC over MQ, где:
— сервис A кладёт сообщение в очередь
— сервис B обрабатывает его и отправляет ответ в «reply queue»
— сервис A продолжает выполнение после получения ответа
На бумаге — асинхронность. На практике — тот же синхронный вызов, только скрытый в очередях и callback’ах.
Чем это опасно?

1. А смысл?
Команда думает: «Мы же используем брокер, всё асинхронно». На деле — они не избавились от синхронности, а просто спрятали её глубже, добавив ещё больше точек отказа.

2. Хрупкость цепочки
Теперь между клиентом и исполнителем не один сетевой хоп, а два, три или четыре: публикация, маршрутизация, обработка, обратная публикация. Любой сбой превращает ответ в «висит, но непонятно где».

3. Возврат к блокирующей модели
Треды всё равно ждут ответа. В результате система одновременно не получает преимуществ асинхронности и тащит всю связанную сложность.

🗼Итог: RPC поверх брокера ломает саму идею асинхронной архитектуры, превращая её в более сложный вариант привычного синхронного вызова.