eventual consistency, CQRS, event sourcing을 사용해 서비스 간 일관성을 어떻게 달성하나요?

Question

Accepted Answer

서비스 간에는 보통 **강한(strong)** 일관성을 **eventual consistency(최종 일관성)**와 맞바꾸고, 이를 실용적이고 정확하게 만들기 위해 **CQRS**와 **event sourcing**에 의존합니다.

## Eventual consistency

변경 후 복제본은 즉시가 아니라 "곧" 수렴합니다. 대부분의 비즈니스 흐름(재고 수량이 1초 늦어도 됨)에는 허용되지만, 일부(은행 잔액 확인)에는 허용되지 않습니다.

## CQRS(Command Query Responsibility Segregation)

**쓰기 모델(write model)**과 하나 이상의 **읽기 모델(read model)**을 분리합니다.

```text
Command ─▶ Write model ─이벤트 방출─▶ [ Read model(s) ]
Query ──────────────────────────────▶ Read model (비정규화, 빠름)
```

읽기는 쓰기와 독립적으로 확장되고 재구성됩니다. 읽기 모델은 이벤트로부터 갱신되므로 eventually consistent합니다.

## Event sourcing

현재 상태가 아니라 **이벤트의 시퀀스**를 진실의 원천(source of truth)으로 저장합니다. 현재 상태는 이벤트에 대한 fold(접기)입니다.

```text
AccountOpened ─▶ Deposited(100) ─▶ Withdrew(30) ─▶ 상태: balance = 70
(이벤트는 불변 + 추가 전용 → 완전한 감사 + 시간 여행)
```

## 트레이드오프

| 기법 | 이점 | 비용 |
|---|---|---|
| Eventual consistency | 가용성, 확장 | 오래된 읽기, 충돌 |
| CQRS | 읽기/쓰기 확장 | 동기화할 두 모델 |
| Event sourcing | 감사, 재생, 이력 | 스키마/이벤트 진화, 복잡성 |

## 함정

event sourcing을 모든 곳에 도입하지 마세요. 강력하지만 무겁습니다. 감사/이력이 진정으로 중요한 곳에 사용하세요.

## 왜 중요한가

분산 시스템은 강한 일관성, 가용성, 분할 내성을 동시에 모두 가질 수 없으므로, 시니어 설계는 eventual consistency가 허용되는 곳을 선택하는 것입니다.

CQRS와 event sourcing은 eventual consistency를 신뢰할 수 있고 감사 가능하게 만드는 도구를 제공합니다. 하지만 각각 실질적인 복잡성을 더하므로, 기본값으로가 아니라 외과적으로 적용하세요.

기법	이점	비용
Eventual consistency	가용성, 확장	오래된 읽기, 충돌
CQRS	읽기/쓰기 확장	동기화할 두 모델
Event sourcing	감사, 재생, 이력	스키마/이벤트 진화, 복잡성