많은 어플리케이션에서 솔루션은 Event Driven Architecture를 사용하는 것이다. Event Driven Architecture에서는 비즈니스 엔터티를 업데이트하는 경우와 같은 주목할 만한 어떤일이 일어날 때, 마이크로서비스가 이벤트를 발행한다. 다른 마이크로서비스는 이러한 이벤트 구독을 신청한다. 마이크로 서비스가 이벤트를 받았을 때(구독 신청한 이벤트를 수신했을 때), 자신의 비즈니스 엔터티를 업데이트할 수 있게 되므로 더 많은 이벤트를 발행할 수 있게 될 것이다.

여러 서비스에 걸쳐 있는 비즈니스 트랜잭션을 구현할 때 이벤트를 사용할 수 있다. 하나의 트랜잭션은 여러 단계로 이루어져 있다. 각 단계는 비즈니스 엔터티를 업데이트 하고, 다음 단계를 Trigger하는(작동시키는) 이벤트를 발행하는 마이크로서비스로 이루어져 있다. 다음의 순차적인 다이어그램은 주문을 생성할 때, 이용 가능한 신용 한도를 체크하기 위하여 어떻게 Event Driven 접근법이 사용되는지를 보여준다. 마이크로서비스는 Message Broker를 통해 이벤트를 교환한다.

  1. Order Service는 NEW 상태의 주문을 생성하고, Order Created 이벤트를 발행한다.

  2. Customer Service는 Order Created 이벤트를 구독하여 주문에 대한 신용 한도를 예약하고, Credit Reserved 이벤트를 발행한다.

  3. Order Service는 Credit Reserved 이벤트를 구독하여, 주문 상태를 OPEN으로 변경한다.

더 복잡한 시나리오에서는 고객의 신용한도를 체크하는 동시에 재고를 예약하는 것과 같은 추가적인 단계가 포함될 수 있다.

(a) 각 서비스가 데이터베이스를 원자적으로 업데이트하고, 이벤트를 발행한다. -- 나중에 다시 이야기하기로 하자.

(b) Message Broker는 이벤트가 최소한 한번은 전달되도록 보장하고, 그런 다음 여러 서비스에 걸쳐져 있는 비즈니스 트랜잭션을 구현할 수 있다.

이것은 ACID 트랜잭션이 아니라는 것에 주목하는 것이 중요하다. 최종 데이터 일관성과 같은 훨씬 더 약한 보장을 제공한다. (ACID에서와는 다르게 최종적으로 데이터가 일관성을 유지하기만 하면 된다는 의미.) 이러한 트랜잭션 모델을 BASE 모델이라고도 한다.

여러 마이크로서비스가 소유한 데이터를 pre-join(사전 조인)하는 실체화된 뷰를 유지 관리하기 위해 이벤트를 사용할 수도 있다. 뷰를 유지 관리하는 서비스는 관련있는 이벤트를 구독하여 뷰를 업데이트한다. 예를 들어, Customer Orders View를 유지 관리하는 Customer Order View Updater Service는 Customer Service와 Order Service에서 발행한 이벤트를 구독한다.

Customer Order View Updater Service가 Customer나 Order 이벤트를 받을 때, Customer Order View Datastore를 업데이트 한다. MongoDB와 같은 문서 기반 데이터베이스를 사용하여 Customer Order View를 구현하고, 각 Customer별로 하나의 문서로 저장할 수 있다. Customer Order View Query Service는 Customer Order View Datastore에 질의하여 고객과 고객의 최근 주문 내역을 처리한다.

Event-Driven Architecture에는 여러 가지 이점과 단점이 있다. Event-Driven Architecture는 여러 서비스에 걸쳐 있는 트랜잭션을 구현할 수 있고, 최종적인 데이터 일관성을 제공한다. 또다른 이점은 어플리케이션이 실체화된 뷰를 유지 관리할 수 있다는 것이다. 한가지 단점은 ACID 트랜잭션을 사용할 때보다 프로그래밍 모델이 훨씬 복잡하다는 것이다. 종종 어플리케이션 수준의 오류를 복구하기 위해서 보상 트랜잭션을 구현해야만 한다. 예를 들면, 신용한도 확인이 실패할 경우에는 주문을 취소해야만 한다. 또한 어플리케이션은 일관성이 없는 데이터를 처리해야 한다. 운영중인 트랜잭션으로 인해 생성된 변경 사항들을 볼 수 있기 때문이다. 어플리케이션이 아직 업데이트 되지 않은 실체화된 뷰에서 데이터를 조회했을 경우, 데이터 불일치가 발생할 수 있다. 또다른 단점은 이벤트를 구독하는 쪽에서 중복된 이벤트에 대해 감지하고 무시해야 한다는 것이다.