더티 읽기
더티 읽기는 한 사가가 업데이트 중인 데이터를 다른 사가가 읽을 때 발생합니다. FTGO 애플리케이션의 소비자는 각자 신용 한도(credit limit)가 정해져 있고, 주문 취소 사가는 다음과 같은 트랜잭션으로 구성됩니다.
주문 취소 사가와 주문 생성 사가의 실행이 서로 겹쳐(interleaved) 실행 중인데, 소비자가 배달을 취소하기는 너무 늦어서 주문 취소 사가가 롤백되는 경우를 생각해 봅시다. 소비자 서비스를 호출하는 트랜잭션 순서가 이렇게 엉켜 버릴 수 있겠죠.
1. 주문 취소 사가: 신용 잔고를 늘립니다.
2. 주문 생성 사가: 신용 잔고를 줄입니다.
3. 주문 취소 사가: 신용 잔고를 줄이는 보상 트랜잭션이 가동됩니다.
주문 생성 사가는 신용 잔고를 더티 읽기 하게 되고, 소비자는 신용 한도를 초과하는 주문도 할 수 있게 될 것입니다. 실제로 이런 일이 벌어지면 매우 곤란하죠.
애플리케이션에 부정적 영향을 끼치는 비정상은 어떻게 방지할 수 있을까요?
12 역주 : 저자가 다소 뜬금없게 신용 한도, 신용 잔고 같은 용어를 쓰고 있지만, 이 책의 주제인 마이크로서비스 아키텍처를 이해하는 데에는 크게 지장이 없으므로 낯설게 느껴지더라도 대략 ‘그런 업무 처리 로직이 있다’ 정도만 알고 넘어가도 됩니다.