각 서비스가 자체 데이터베이스를 가질 때 데이터를 어떻게 관리하나요?

Question

Accepted Answer

**공유 데이터베이스가 없으면** 서비스 간 JOIN이나 단일 ACID 트랜잭션을 사용할 수 없습니다. **API composition**, **복제/CQRS 읽기 모델**, **이벤트**를 사용해 데이터를 구성하고 일관성을 유지합니다.

## 서비스 간 데이터 읽기

**API composition** — 코디네이터가 각 서비스를 호출하고 결과를 짜맞춥니다:

```js
// 세 서비스로부터 주문 뷰를 구성
const order    = await ordersApi.get(orderId);
const customer = await usersApi.get(order.customerId);   // 별도 서비스
const shipment = await shippingApi.get(orderId);
return { ...order, customer, shipment }; // 메모리에서 구성
```

무거운 쿼리의 경우 **읽기 모델**(CQRS)을 유지합니다. 서비스가 이벤트를 구독하고 직접 질의할 수 있는 비정규화된 로컬 복사본을 구축합니다.

```text
Orders ─event→ ┐
Users  ─event→ ├─▶ [ Order-View 서비스가 자체 질의 가능 테이블 구축 ]
Shipping ─event→ ┘
```

## 서비스 간 쓰기

분산 트랜잭션 대신 **Saga** 패턴 — 보상 작업(compensating action)을 가진 로컬 트랜잭션의 시퀀스 — 을 사용합니다.

## 트레이드오프

| 접근법 | 장점 | 단점 |
|---|---|---|
| API composition | 항상 최신 | 지연, 팬아웃, 취약함 |
| 복제된 읽기 모델 | 빠른 읽기 | eventually consistent |
| Saga | 2PC 불필요 | 복잡, 보상 필요 |

## 함정

조인을 쉽게 하려고 "그냥" 테이블을 공유하지 마세요. 이는 서비스를 다시 결합시킵니다. 비즈니스가 허용하는 곳에서는 eventual consistency를 받아들이세요.

## 왜 중요한가

데이터 관리는 마이크로서비스가 진짜로 어려워지는 지점입니다. 쉬운 도구(조인, 트랜잭션)가 설계상 사라졌기 때문입니다.

composition, 읽기 모델, saga를 이해하는 것이 정확성을 잃지 않으면서 서비스를 독립적으로 유지하게 해줍니다.

접근법	장점	단점
API composition	항상 최신	지연, 팬아웃, 취약함
복제된 읽기 모델	빠른 읽기	eventually consistent
Saga	2PC 불필요	복잡, 보상 필요