🟢 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]]