Подделка взаимодействия!

Есть два подхода, которые почти всегда вызывают споры:
👯‍♀️💃 синхронка поверх асинхронки
💃👯‍♀️ асинхронка поверх синхронки

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

Давайте разберем любимое — асинхронка на синхронке.

Как это выглядит на практике:
1️⃣ система X отправляет синхронный запрос
2️⃣ система Y синхронно отвечает: «принял, вот id»
3️⃣ система X:
- либо ждет
- либо ходит опрашивать статус
4️⃣ когда что-то изменилось — Y шлет webhook

Снаружи — синхронный API.
По факту — распределенный асинхронный процесс.

Когда это нужно

🤖Интеграционные гейты и мерчанты.

У вас есть N клиентов, которым нужно:
- понимать, что произошло
- получать однозначные ответы
- не разбираться в очередях и событиях

А внутри вы хотите:
- строить очередь
- ретраить
- управлять нагрузкой

В итоге вы даете им синхронный контракт, но живете в асинхронной модели.

🤺Саги и каскадирование.

Процесс стартует в одном сервисе → уходит в другой → дальше цепочка шагов, ретраев, откатов.

Но у первого сервиса:
- свои таймауты
- свои SLA
- необходимость понимать, что произошло

Поэтому:
- снаружи он делает «синхронный» вызов
- внутри запускается асинхронная сага

🤔 Пользовательские сценарии (UI).

Есть запрос из:
- мобильного приложения
- веба

И где-то в цепочке появляется прокси-сервис, который:
- агрегирует
- модифицирует
- маршрутизирует

Но при этом:
- жесткие таймауты
- нельзя держать соединение долго
- пользователь ждет ответ «сейчас»

Решение:
- быстро принять запрос
- отдать «синхронный» результат
- остальное доделать асинхронно

❓Что еще сюда попадает

Если посмотреть шире, таких сценариев больше:
⏱️ Долгие внешние интеграции
Когда вы ходите во внешние системы с непредсказуемой латентностью и не хотите держать открытое соединение
⛓️‍💥 Нестабильные провайдеры
Когда нужны ретраи, фолбэки, каскадирование, но клиенту это показывать нельзя
🎛️ Регуляторные процессы
Когда важно зафиксировать факт «запрос принят» даже если обработка займет часы
🛟 Буферизация нагрузки
Когда входящий поток нужно сгладить очередью
но API при этом остается синхронным

Почему это вызывает споры?
Потому что это компромисс.
Мы:
- упрощаем контракт снаружи
- усложняем систему внутри

И создаем риск:
- «ответ уже был, а результат еще меняется»
- рассинхронизации статусов
- сложного дебага

Но при этом без этого паттерна:
- не живут платежные гейты
- не строятся интеграционные слои с внешними мерчантами

💬 А теперь вопрос:
если мы умеем делать асинхронку на синхронке…
зачем тогда делают наоборот?

Про синхронку поверх асинхронки — в следующем посте.