🟢 Junior Level

Синхронная — отправил запрос и ждёшь ответ (как телефонный звонок).

Асинхронная — отправил сообщение и забыл, ответ придёт когда будет готов (как email).

Синхронная:
Service A → запрос → Service B → ответ → Service A (ждёт)

Асинхронная:
Service A → сообщение → Queue → Service B (заберёт когда готов)

---

🟡 Middle Level

Синхронная

HTTP/REST:

ResponseEntity<User> response = restTemplate.getForEntity(
    "http://user-service/users/{id}", User.class, userId);

gRPC:

UserResponse user = userServiceBlocking.getUser(UserRequest.newBuilder()
    .setUserId(userId).build());

Плюсы:

• Простота
• Мгновенный ответ

Минусы:

• Cascading failures
• Coupling во времени

Асинхронная

Kafka:

kafkaTemplate.send("user-events", event); // Возвращает Future/ListenableFuture
// Можно дождаться подтверждения от брокера, но обычно fire-and-forget.

Плюсы:

• Отказоустойчивость
• Масштабируемость

Минусы:

• Eventual consistency
• Сложнее дебажить

Типичные ошибки

1. Синхронная для долгих операций:

   HTTP запрос на 30 секунд → timeout
   Решение: асинхронная + polling/webhook
   

---

🔴 Senior Level

Архитектурные Trade-offs

Синхронная	Асинхронная
Strong consistency	Eventual consistency
Проще	Отказоустойчивее
Меньше latency: прямой вызов, нет overhead на broker.	Больше throughput: broker буферизует запросы, потребитель обрабатывает в своём темпе.
Cascading failures	Buffering

Production Experience

Комбинированный подход:

Синхронная: запрос данных (read)
Асинхронная: события, команды (write)

Best Practices

// Если использовать async для критичных данных (платёж):
// вы не узнаете результат мгновенно — пользователь висит в ожидании.
// Нужен polling или callback, что усложняет UX.
✅ Синхронная для простых read операций
✅ Асинхронная для событий и команд
✅ Circuit Breaker для синхронных
✅ Idempotency для асинхронных

❌ Синхронные цепочки > 2 сервисов
❌ Асинхронная для критичных данных

---

🎯 Шпаргалка для интервью

Обязательно знать:

• Синхронная: отправил → ждёшь ответ (как телефон), strong consistency, меньше latency
• Асинхронная: отправил → забыл, ответ придёт когда будет готов (как email), eventual consistency
• Синхронная: HTTP/REST, gRPC — проще, но cascade failure risk
• Асинхронная: Kafka, RabbitMQ — отказоустойчивее, buffer для пиков нагрузки
• Комбинированный подход: синхронная для read, асинхронная для write/events
• Синхронная для критичных данных (платёж) — пользователь ждёт результат
• Асинхронная для критичных данных сложнее: нужен polling/callback

Частые уточняющие вопросы:

• Когда выбрать синхронную? Простые read операции, нужен мгновенный ответ, < 2 сервисов в цепочке.
• Когда выбрать асинхронную? События, команды (write), фоновые задачи, высокая нагрузка.
• Почему cascade failure в синхронной? A→B→C→D, D упал → все зависли → цепная реакция.
• Что такое thundering herd? Множество клиентов одновременно повторяют вызов — нужен jitter.

Красные флаги (НЕ говорить):

• “Синхронная всегда быстрее” — да, для простых случаев, но cascade failure может сделать медленнее
• “Асинхронная = fire and forget” — нет, нужен monitoring и обработка ошибок
• “Синхронная цепочка 5 сервисов — норм” — нет, cascade failure risk
• “Асинхронная для платежей” — сложно, пользователь висит в ожидании

Связанные темы:

• [[15. Как организовать коммуникацию между микросервисами]]
• [[5. Что такое паттерн Circuit Breaker]]
• [[19. Что такое паттерн Retry и как его правильно использовать]]
• [[20. Что такое exponential backoff]]
• [[2. В чём разница между хореографией и оркестрацией в Saga]]