Event Driven System

EDA(Event Driven Architecture) 의 핵심은 당연, Event 이다. Application 에서 발생하는 Event 의 종류를 두 가지로 나눌 수 있다.

  1. Internal Event
  2. External Event

내부 이벤트(internal event)의 경우에는 비관심사 를 분리 하는 것이 주 목적이다. 다시 말하면, 도메인 로직 과 도메인 로직에 붙어있는 부가적인 정책 을 분리 하는 것을 의미한다.

외부 이벤트(external event)의 경우에는 외부 시스템과의 의존성 격리 가 주 목적이다. 이벤트 발행처(publisher)는 이벤트를 발행할 뿐, 구독자(subscriber) 가 발행된 이벤트를 가지고 무엇을 하는지 알 필요가 없다. 구독자가 비지니스 로직을 처리하는데 필요한 이벤트를 발행처에서 담아서 발행하는 순간 결합(coupling) 이 생기게 된다.

ZERO-PAYLOAD

ZERO-PAYLOAD 방식이란 이벤트 발행에 ID 와 몇 가지 정보만 넣어서 보내고 이외의 필요한 정보는 수신한 곳에서 ID 를 기반으로 API 를 호출하여 데이터를 채워서 처리하는 방식을 의미한다. 장점은 새로운 요구 사항에 따라 Event Data 가 재설계될 필요가 없다.

Saga

Saga 패턴은 데이터 일관성을 보장하고 이벤트 중심 시스템에서 비즈니스 트랜잭션을 관리하는 데 도움을 주는 패턴이다.

The output/event/action result of one service is translated into the input/command/action of another service. This is the essence of the Saga pattern. It reacts!

Imagine extending this saga to include compensating actions in case of order being rejected:

Event Sourcing

이벤트 소싱 패턴(event sourcing pattern) 은 아래와 같은 문제를 해결할 수 있다.

Problems:

  • 데이터베이스를 원자적으로 업데이트하고 메시지 브로커에 메시지를 보내는 방법

Strengths:

  • 데이터베이스 트랜잭션이 커밋되면 메시지를 보내야 한다. 반대로 데이터베이스가 롤백되면 메시지가 전송되어서는 안 된다.
  • 메시지는 서비스에서 전송한 순서대로 메시지 브로커로 전송되어야 한다.
  • 2PC 는 고려 대상이 아니다.
    • 데이터베이스에서 2PC 를 지원 안할 수도 있고, 무엇보다 성능이 너무 떨어진다.

Solution:

Event sourcing persists the state of a business entity. state-changing events are stored as a sequence of events.

이벤트 데이터베이스인 이벤트 저장소에 이벤트를 유지한다.

애플리케이션은 항상 일관된 데이터 처리를 해야 하고, 쿼리를 하기 위해서는 CQRS 패턴을 사용해야 한다.