Bez wspólnej bazy danych nie możesz używać cross-service JOINów ani pojedynczych transakcji ACID. Składasz dane i zachowujesz spójność za pomocą API composition, replication/CQRS read models i events.
Odczyt danych między usługami
API composition — koordynator wywołuje każdą usługę i łączy wynik:
// build an order view from three services
const order = await ordersApi.get(orderId);
const customer = await usersApi.get(order.customerId); // separate service
const shipment = await shippingApi.get(orderId);
return { ...order, customer, shipment }; // composed in memory
Dla ciężkich zapytań utrzymuj read model (CQRS): usługa subskrybuje zdarzenia i buduje denormalizowaną lokalną kopię, którą może bezpośrednio pytać.
Orders ─event→ ┐
Users ─event→ ├─▶ [ Order-View service builds its own queryable table ]
Shipping ─event→ ┘
Zapis między usługami
Użyj wzorca Saga — sekwencji lokalnych transakcji z akcjami kompensacyjnymi — zamiast transakcji rozproszonej.
Dlaczego to ważne
| Podejście | Zaleta | Wada |
|---|---|---|
| API composition | Zawsze świeże | Opóźnienie, fan-out, kruche |
| Replicated read model | Szybkie odczyty | Ostatecznie spójne |
| Saga | Nie trzeba 2PC | Złożone, wymaga kompensacji |
Pułapka
Nie dziel po prostu tabeli, aby ułatwić join — to ponownie łączy usługi. Zaakceptuj spójność ostateczną tam, gdzie biznes na to pozwala.
Dlaczego to ważne
Zarządzanie danymi to miejsce, gdzie microservices naprawdę stają się trudne, ponieważ łatwe narzędzia (joins, transactions) zniknęły z projektu.
Zrozumienie composition, read models i sagas to to, co pozwala Ci utrzymywać usługi niezależne bez utraty poprawności.