Синхронна взаємодія - сервіс надсилає запит (HTTP, gRPC) і чекає відповіді, перш ніж продовжити:
Замовлення → HTTP → Склад: «зарезервуй товар» → чекає → «зарезервовано» → продовжує
Асинхронна - сервіс надсилає повідомлення (у чергу, брокер, шину подій) і не чекає. Отримувач обробить його, коли зможе:
Замовлення → подія OrderPlaced → черга → Склад обробить пізніше
→ Сповіщення обробить пізніше
Синхронна - переваги й недоліки:
- проста модель: запит - відповідь, легко зрозуміти й налагоджувати;
- результат одразу - потрібно, коли відповідь потрібна користувачу прямо зараз (ціна, наявність, перевірка прав);
- часова зв'язаність: якщо склад недоступний чи повільний, оформлення замовлення теж падає чи гальмує;
- ланцюжки викликів множать затримки й імовірність збою: п'ять сервісів з доступністю 99,9% кожен дають ланцюжок з ~99,5%.
Асинхронна - переваги й недоліки:
- незалежність: отримувач може бути тимчасово недоступний - повідомлення почекає в черзі;
- згладжування піків: черга накопичує роботу, обробники беруть її у своєму темпі;
- легко додати нових отримувачів подій без зміни відправника;
- кінцева узгодженість: результат з'являється не одразу - інтерфейс і бізнес-процеси мають це враховувати;
- складніше налагоджувати: потрібні трасування, ідентифікатори кореляції, обробка дублікатів і повідомлень, що не вдалося обробити (dead letter queue).
Як обирати:
- запит від користувача, що потребує відповіді (прочитати дані, перевірити) - синхронно, з тайм-аутами й запасним варіантом;
- реакція на подію (надіслати лист, оновити аналітику, синхронізувати пошуковий індекс) - асинхронно;
- довгі операції (генерація звіту, обробка відео) - асинхронно з відповіддю
202 Acceptedі статусом.
У межах одного Laravel-застосунку той самий вибір: синхронний виклик сервісу чи dispatch() джоби в чергу. Асинхронність через черги - перший крок до розподіленої архітектури навіть у моноліті.
Докладніше в документації: Microsoft: взаємодія в мікросервісній архітектурі