msa, 풀어쓰면 micro service architecture인가 그럴거다. 

통짜로 되어있는 기존 솔루션을 독립적인 작은 단위로 쪼개고, 표준화된 restful api로 통신하도록 구성하는 방법인데 이론으로는 굉장히 트렌디하지만 실무에 실상 쉽게 끌어다 쓰기 힘든 제일 큰 이유는 트랜잭션이다. 

비즈니스 로직들은 당연히 플로우 안에서 fail이 나면 전체가 rollback이 되도록 트랜잭선으로 구성해주는 것이 맞는데

통짜 솔루션에서는 이 트랜잭션 구성이 쉽지만 독립된 서비스들로 구성된 msa에서는 이러한 트랜잭션을 구현하는 것이 쉽지 않다.

이러한 트랜잭션을 보장하기 위한 가장 일반적인 방법으로는 보상 트랜잭션을 구현하는 것이 보통이다.

db로 예를 들면 전통적인 트랜잭션 기법처럼 insert 후에 rollback 액션을 취하는 것이 아니라 insert 후에 fail이 난다면 delete를 해주는 방식을 말한다.

언젠가 msa에서 트랜잭션 구성을 위한 방법을 누가 물어왔을 때 나는 보상 트랜잭션이 그 답이라고 생각하고 답변했다.

근데 곰곰히 생각해보면 베스트 답변은 아니다.

베스트 답변은 사실 각각의 독립된 서비스들이 하나의 트랜잭션으로 묶이게 애초에 구성하지 않는 것이었다.

아무리 보상 트랜잭션을 잘 만들어준다고 해도 기존 트랜잭션에 비해서 안정성이 떨어지게 마련이고 구현의 난이도도 굉장히 높다. 

특히나 데이터의 정합성이 중요한 솔루션에서는 애초에 독립된 서비스들이 하나의 트랜잭션으로 묶이게 설계가 되어서는 안된다.

즉, msa에서 트랜잭션을 고민하게 되는 상황 자체가 설계 미스라고 볼 수도 있다.