strong consistency vs eventual consistency

https://www.acodersjourney.com/eventual-consistency/

System Design Interview Concepts – Eventual Consistency

 

strong consistency (=immediate consistency, strict consistency)

- 클라이언트가 write 작업이 일어나면, 모든 replica 서버에 업데이트 값이 적용되는 것 

- 이렇게 하기 위해서는, 모든 replica 노드에서 업데이트 값이 적용되기 전까지, block이 발생됨. 

 

 

eventual consistency 

- 클라이언트에서 write작업이 발생하면, block이 발생하지 않고, 노드에서 알아서 업데이트가 발생하는 것.

- 일시적으로 클라이언트마다 다른 버전의 데이터를 받게 될 수 있지만, 언젠가 동기화가 되면 최종적으로는 모든 클라이언트가 동일하게 데이터를 받게됨

- 적용 예시 

> 사진 공유 시스템 

> 페이스북이나 트위터의 타임라인

> DNS (Domain Name System)

 

cf. MSA에서의 Eventual Consistency

출처 : https://www.yes24.com/Product/Goods/98880996

도메인 주도 설계로 시작하는 마이크로서비스 개발 - YES24

- 마이크로서비스는 폴리글랏 저장소 접근법을 선택하여 서비스별로 데이터베이스를 갖도록 설계를 하게 된다.
> 즉, 각 저장소가 서비스별로 분산돼 있어야 하며, 다른 서비스의 저장소를 직접 호출할 수 없고 API 통해서만 접근해야 한다.

- 이 때 데이터베이스의 일관성 처리 문제가 발생하는데, 각각 다른 서비스를 트랜잭션으로 묶는 경우 서비스의 독립성도 떨어지고 noSQL 처럼 2단계 커밋을 지원하지 않는 경우가 있으므로 비동기 이벤트 처리를 통한 일관성을 강조한다. Eventual Consistency 라는 개념임

- 두 서비스의 데이터가 일시적으로 불일치하는 시점이 있고 일관성이 없는 상태이지만 결국에는 두 데이터가 같아진다는 개념. 즉, 여러 트랜잭션을 하나로 묶지 않고 별도의 로컬 트랜잭션을 각각 수행하고 일관성이 달라진 부분은 체크해서 보상 트랜잭션으로 일관성 맞추는 개념이다.

 

1. 주문 서비스가 주문 처리 트랜잭션을 수행한다.
   1. 동시에 주문 이벤트를 발생한다.
   2. 주문 이벤트가 메시지 큐로 전송된다.
   3. 배송 서비스가 주문 이벤트를 인식한다.
2. 배송 서비스가 주문 처리에 맞는 배송 처리 트랜잭션을 수행한다. (비즈니스 일관성 만족)
3. 배송 처리 트랜잭션 중 오류로 트랜잭션을 실패한다.
   1. 배송 처리 실패 이벤트를 발행한다.
   2. 배송 처리 실패 이벤트가 메시지 큐로 전송된다.
   3. 주문 서비스가 배송 처리 실패 이벤트를 인식한다.
4. 주문 서비스가 배송 처리 실패 이벤트를 인식한다. (비즈니스 일관성 만족)

 

 

---

https://www.yes24.com/Product/Goods/98880996

도메인 주도 설계로 시작하는 마이크로서비스 개발 - YES24

https://www.acodersjourney.com/eventual-consistency/

System Design Interview Concepts – Eventual Consistency