Без общей базы данных вы не можете использовать кросс-сервисные JOINы или отдельные ACID-транзакции. Вы комбинируете данные и сохраняете их согласованность, используя API composition, replication/CQRS read models и events.
— координатор вызывает каждый сервис и объединяет результат:
// 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
Для тяжёлых запросов поддерживайте read model (CQRS): сервис подписывается на события и создаёт денормализованную локальную копию, которую может запрашивать напрямую.
Orders ─event→ ┐
Users ─event→ ├─▶ [ Order-View service builds its own queryable table ]
Shipping ─event→ ┘
Используйте паттерн Saga — последовательность локальных транзакций с компенсирующими действиями — вместо распределённой транзакции.
| Подход | Преимущество | Недостаток |
|---|---|---|
| API composition | Всегда свежие | Задержка, fan-out, хрупкость |
| Replicated read model | Быстрое чтение | Итоговая согласованность |
| Saga | 2PC не нужен | Сложность, требует компенсации |
Не просто разделяйте таблицу, чтобы упростить join — это повторно связывает сервисы. Принимайте итоговую согласованность, где это допускает бизнес.
Управление данными — это место, где микросервисы действительно становятся сложными, потому что простые инструменты (joins, transactions) исчезли по замыслу.
Понимание composition, read models и sagas — это то, что позволяет вам держать сервисы независимыми без потери корректности.