Jak mikroserwisy komunikują się ze sobą?

Question

Accepted Answer

Usługi komunikują się albo **synchronicznie** (żądanie/odpowiedź poprzez REST lub gRPC), albo **asynchronicznie** (wiadomości/zdarzenia przez brokera, takiego jak Kafka lub RabbitMQ).

## Synchronicznie (żądanie/odpowiedź)

Wywoływający czeka na odpowiedź. Proste i intuicyjne, ale łączy dostępność — jeśli wywoływany jest niedostępny, wpływa na wywoływającego.

```http
GET /orders/42 HTTP/1.1
Host: orders-service
Accept: application/json
```

## Asynchronicznie (wiadomości/zdarzenia)

Nadawca publikuje wiadomość i idzie dalej; konsumenci przetwarzają ją później. To rozdzielenie usług w czasie.

```text
Order Service ──publish "OrderPlaced"──▶ [ Broker ] ──▶ Email Service
                                              │
                                              └──▶ Inventory Service
```

## Kiedy używać który sposób

| Potrzeba | Wybierz |
|---|---|
| Natychmiastowa odpowiedź dla użytkownika | Synchronicznie |
| Rozdzielenie, buforowanie, fan-out | Asynchronicznie |
| Silne czasowe sprzężenie OK | Synchronicznie |
| Odporność na awarie w dół | Asynchronicznie |

## Pułapka

Długie **łańcuchy synchroniczne** (A → B → C → D) mnożą opóźnienie i prawdopodobieństwo awarii. W miarę możliwości preferuj async lub agregację.

## Dlaczego to ważne

Styl komunikacji kształtuje odporność systemu: synchroniczne wywołania są łatwe do wyjaśnienia, ale tworzą ścisłe sprzężenie w czasie wykonywania, podczas gdy asynchroniczne wiadomości kupują rozdzielenie za cenę ostatecznej spójności.

Większość prawdziwych systemów łączy oba podejścia — sync dla odczytów skierowanych do użytkownika, async dla procesów w tle.

Potrzeba	Wybierz
Natychmiastowa odpowiedź dla użytkownika	Synchronicznie
Rozdzielenie, buforowanie, fan-out	Asynchronicznie
Silne czasowe sprzężenie OK	Synchronicznie
Odporność na awarie w dół	Asynchronicznie