대규모 분산 시스템에서 장애 전파를 줄이고, 비동기 워크플로를 유연하게 처리하기 위한 핵심 전략은 무엇일까?
이 포스트에서는 메시지 기반 아키텍처와 이벤트 기반 설계에 대해 알아본다.

DDD(1) - 이벤트 주도 아키텍처(EDA, Event-Driven Architecture) 와 함께 보세요.

<이벤트 중심 아키텍처를 선택하는 이유>
전통적인 요청-응답 기반 시스템은 서비스 간 강한 결합을 유발하고, 하나의 장애가 전체 시스템 장애로 확산되는 연쇄 장애의 위험이 있다.
특히 클라우드 기반 분산 시스템에서는 네트워크 지연이 예측하기 어렵기 때문에 이를 우아하게 처리하기 위한 아키텍처가 필요하다.
이런 문제를 해결하기 위해 메시징 인프라와 이벤트 주도 아키텍처(EDA, Event-Driven Architecture) 가 도입되었다.
이벤트 중심 아키텍처는 분산 시스템에서 필연적으로 발생하는 지연, 오류, 복잡도를 우아하게 다루기 위한 접근 방식이다.

대규모 시스템에서는 비즈니스 프로세스가 여러 서브시스템에 걸쳐 분산되며, 이들을 효과적으로 조율할 필요가 있다.
이를 위해 대표적으로 사용하는 두 가지 워크플로 관리 방식:

• 코레오그래피(Choreography): 느슨한 결합
• 오케스트레이션(Orchestration): 중앙 집중 조율

<이벤트 소싱: 이벤트 기반 감사 추적과 변경 이력 관리>

• 서브시스템의 모든 데이터 변경을 추적하고 감사 로그를 남기기 위한 기술로 이벤트 소싱이 사용된다.
• 이 방식을 통해 언제, 누가, 어떤 이유로 데이터를 변경했는지에 대한 명확한 기록을 유지할 수 있다.

<CQRS>

• 데이터 변경을 일으키는 커맨드와 데이터를 조회하는 쿼리를 분리하는 CQRS 패턴이 유용한 경우가 많다.
• 예)
  • 변경 대상 데이터는 제한된 속성만 필요
  • 사용자에게 보여지는 데이터는 복잡하고 풍부한 가공 정보 필요
• 이 경우 쓰기 모델은 간결하게, 읽기 모델은 최적화된 형태로 분리하여 관리할 수 있다.

이벤트 소싱과 CQRS 는 데이터를 다루는 방식에 유연성과 추적 가능성을 더해준다.

목차

• 1. 코레오그래피(Choreography) vs 오케스트레이션(Orchestration)
  • 1.1. 코레오그래피: 분산된 주체의 자율적 상호작용
  • 1.2. 오케스트레이션: 중앙 집형형 프로세스 조율
• 2. 액터 모델(Actor Model): 동시성과 확장성에 최적화된 설계
• 3. 메시지 및 이벤트 기반 REST
  • 3.1. 이벤트 로그
  • 3.2. 구독자 폴링
  • 3.3. 서버 전송 이벤트(SSE, Server-Sent Events)
• 4. 이벤트 주도 및 프로세스 관리
• 5. 이벤트 소싱
• 5. CQRS
• 7. 서버리스와 FaaS: 인프라 걱정없는 이벤트 기반 설계
• 정리하며..
• 참고 사이트 & 함께 보면 좋은 사이트

1. 코레오그래피(Choreography) vs 오케스트레이션(Orchestration)

코레오그래피와 오케스트레이션은 이벤트 기반 아키텍처에서 서비스 간 워크플로를 어떻게 설계할 것인가에 대한 핵심 전략이다.

REST 나 RPC 는 네트워크 장애, 타임아웃, 서로 다른 서비스 간 시간적 결합 때문에 연쇄 장애가 발생하기 쉽다.
반면, 비동기 메시징은 요청과 응답이 시간적으로 분리되어 이러한 실패 전파를 줄이는 데 유리하다.

메시지 흐름은 시간 지연을 허용하므로 10초 이상 처리 시간이 소요되더라도 프로세스 자체가 실패하진 않는다.
반면, REST 요청은 5초 타임아웃이면 실패로 간주되며, 전체 흐름이 끊길 수 있다.
이처럼 이벤트 기반 메시징 아키텍처는 느린 프로세스나 비동기 처리를 보다 안정적으로 지원한다.

1.1. 코레오그래피: 분산된 주체의 자율적 상호작용

각 서브시스템이 자율적으로 이벤트에 반응하며, 프로세스를 주도한다.
중앙 제어자가 존재하지 않으며, 이벤트 흐름 자체가 프로세스를 이끈다.
예) 주문 → 결제 완료 이벤트 → 배송 시스템이 이벤트 수신 후 처리 시작

<코레오그래피 장점>

• 시스템이 느슨하게 결합됨
• 설계 및 구현이 단순하고 직관적임
• 개별 컨텍스트가 개별적으로 동작

<코레오그래피 단점>

• 프로세스 중단 시 문제 위치 추적이 어려움
• 이벤트를 소유하지 않은 시스템도 주관적으로 해석하고 반응해야 함
• 추론 기반 비즈니스 로직이 외부에 분산되어 복잡도 증가

코레오그래피는 프로세스 단계가 적을 때 실용적이다.

• 계약 심사, 리스크, 보험료율 3개의 서브시스템은 총 6단계에 걸친 프로세스를 실행
• 계약 심사 시스템은 결과에 도달하는데 관련된 세부 사항은 잘 알지 못함
• 신청서 제출 이벤트가 발생된 후 미래의 어느 시점에 계약 심사 견적 가능한 보험료율을 사용할 수 있다는 알림이 전송됨
• 이 구조는 리액티브 아키텍처(메시지 주도 아키텍처)의 특징을 따름

메시지 주도 아키텍처는 컴포넌트들이 수동적으로 있다가 메시지에 의한 자극에 의해 반응하기 때문에 리액티브(반응형) 아키텍처라고도 한다.

<메시지 주도 아키텍처(리액티브 아키텍처)의 4가지 핵심 특성>

• 반응성(Responsive)
• 복원성(Resilient)
• 탄력성(Elastic)
• 메시지 주도(Message-driven)

1.2. 오케스트레이션: 중앙 집형형 프로세스 조율

오케스트레이터가 모든 단계의 흐름을 알고, 각 서브시스템에 명시적 명령을 보내며, 대표 구현으로는 사가(Saga)가 있다.

<오케스트레이션 장점>

• 문제 발생 지점이 명확하여 추적 용이
• 상태, 에러, 타임라인 등을 명시적으로 관리 가능
• 각 시스템은 로직에 대해 불필요한 추론 없이 명확한 작업만 수행

<오케스트레이션 단점>

• 오케스트레이터는 중앙 집중 지점이자 단일 장애 지점이 될 수 있음
  • 하지만 분산 시스템의 일반적인 확장성/Failover 전략으로 완화 가능
• 비즈니스 로직이 오케스트레이터에 과도하게 집중되면 설계가 뚱뚱해질 수 있음
  • 따라서 오케스트레이터는 단순한 흐름 제어자로 역할에만 사용되어야 함

오케스트레이션은 복잡한 단계가 많고, 상태 관리나 오류 처리의 필요성이 클 경우 적합하다.

2. 액터 모델(Actor Model): 동시성과 확장성에 최적화된 설계

복잡한 시스템에서의 동시성 문제, 스레드 간 경합, 확장성 한계는 오래된 고민이다.
액터 모델은 이러한 문제를 구조적으로 해결할 수 있는 효과적인 동시성 처리 모델로, 특히 메시지 기반 시스템과 자연스럽게 통합된다.

액터 모델은 메시지를 중심으로 구성된 객체 모델로, 상호 격리된 단위들이 병렬로 동작하면서도 안전하게 메시지를 주고 받을 수 있는 구조를 제공한다.
특히 도메인 로직과 인프라 문제를 철저히 분리하는데 탁월한 설계 기반으로 제공한다.
애플리케이션 서비스가 없는 구조에서도 메시지 기반 액터들이 도메인 로직을 수행하며, 설계적으로 격리된 상태를 유지할 수 있다.
따라서 서비스 레이어가 얇거나 존재하지 않아야 하는 아키텍처에 잘 어울린다.

<액터 모델이란?>
액터 모델은 메시지 기반으로 동작하는 객체 시스템으로, 자율적이고 독립적으로 동작하는 컴포넌트(액터)들이 비동기 메시지를 주고받으며 상태를 관리하는 모델이다.
각 액터는 아래 3가지 행동을 할 수 있다.

• 메시지를 수신하여 처리
• 새로운 액터 생성
• 다른 액터에게 메시지 전송

공유 상태는 없으며, 각 액터는 자신의 상태를 직접 관리한다.
이는 동시성 환경에서의 lock 경쟁을 없애고, race condition 문제를 자연스럽게 피하게 해준다. 메시지는 비동기적으로 전달되고, 순차적으로 처리된다.

<액터 모델의 아키텍처적 이점>

• 동시성 & 확장성에 유리
  • 액터는 독립적으로 실행되므로 멀티코어 환경에서 자연스럽게 병렬화 가능
  • 메시지 큐 기반 구조로 설계 가능(확장성 높음)
  • 다수의 액터가 동시에 메시지를 처리하여 수평 확장성 확보
    • 모든 액터는 한 번에 하나의 메시지만 처리하므로 액터는 액터는 개별적으로 단일 스레드이지만, 많은 액터가 짧은 시간동안 동시에 메시지를 처리하면 대규모의 동시성을 갖게됨
• 격리된 상태 관리와 안정성
  • 액터는 자신의 상태만 직접 변경할 수 있고 외부에서는 접근 불가 → race condition 없음
  • 한 액터는 한 번에 하나의 메시지만 처리(싱글 스레드)
    • 이는 동시에 들어오는 2개 이상의 스레드가 서로 내부 상태 데이터를 사용하지 못하게 보호할 필요가 없다는 것을 의미함
• 메시지 기반 의사소통
  • 비동기 메시지 전달 → 느슨한 결합
  • 액터 간의 인터페이스는 오직 메시지
• 도메인 로직과 인프라의 분리
  • 설계 상 액터는 다른 액터들과 물리적으로 격리되기 때문에 도메인 로직(비즈니스 규칙)과 인프라 로직(I/O, DB 연동 등) 이 명확히 분리될 수 있음
  • 서비스 레이어가 없어도 도메인 액터가 자체적으로 도메인 로직을 수행
• 운영 비용 절감
  • 액터 모델 특성 상 모든 컴퓨터 프로세스가 항상 사용됨

액터 모델 구조 예시

• 메시지 브리지 액터가 메시지 버스로부터 ‘신청서 제출됨’ 이벤트를 수신한 후 리스크 평가 서비스 액터가 사용할 수 있는 내부 메시지 형태로 변환
• 변환된 메시지를 다음 액터로 비동기 메시지 전송

<액터 모델 기반 아키텍처에서의 구성>

• 수신 어댑터(Receiving Adapter): 외부로부터의 요청 또는 이벤트를 받아 해당 메시지를 적절한 도메인 모델 객체(액터)에게 디스패치함
  • 외부로부터 이벤트 수신 → 적절한 도메인 액터로 전달
  • 전통적인 서비스 레이어(애플리케이션 서비스)는 존재하지 않을 수 있음
  • 대신 각 도메인 액터가 메시지를 받고 자체적으로 동작
• 도메인 액터(Domain Actor): 각 기능 단위의 도메인 로직을 자체적으로 수행
  • 명령 메시지 수신 → 도메인 로직 수행 → 상태 변경 or 메시지 전파
  • 로직과 상태의 응집도가 높음

<액터 모델 적용 시 고려할 점>

• 메시지 설계
  • 액터 간 통신은 메시지로만 이루어지므로, 명확한 메시지 정의가 매우 중요
• 장애 전파 방지
  • 액터 간 실패 격리 구조 설계 필요 (예: supervisor model)
• 상태 복구
  • 상태 저장 및 복원 메커니즘 필요 (예: 이벤트 소싱)
• 배포 전략
  • 액터를 클러스터링하거나 분산 배치할 때 고려사항 많음

3. 메시지 및 이벤트 기반 REST

어떻게 REST 가 메시지 및 이벤트 주도 아키텍처를 지원할 수 있을까?

REST 는 요청-응답의 동기 처리만을 위한 것이 아니다.
HTTP 메시지 기반 모델을 활용하면 REST 도 이벤트 주도 아키텍처의 일부로 작동할 수 있다.

• HTTP 는 기본적으로 요청-응답이 메시지로 구성된 프로토콜이다.
• REST 는 메시지 주도 설계이며, 이벤트는 이 중 특별한 메시지 유형으로 볼 수 있다.
• REST 에서 이벤트 주도성을 구현하려면 이벤트 소비를 비동기 처리로 전환해야 한다.

3.1. 이벤트 로그

이벤트 주도 시스템의 핵심은 불변 로그이다.

<이벤트 로그 원칙>

• 이벤트는 한 번 기록되면 변경되지 않아야 한다.
• 오류가 있는 이벤트가 기록된 경우, 보상 이벤트를 추가로 생성해야 하며, 기존 이벤트를 수정해서는 안된다.
• 이는 이벤트 소싱과 유사한 불변성 모델을 따른다.

<기술적 고려사항>

• 각 이벤트는 단조 증가하는 시퀀스 번호를 통해 순서를 보장
• 관계형 DB 도 사용할 수 있지만, 로그 성능은 전용 이벤트 저장소가 더 뛰어남
• 이벤트가 많아지면 디스크 공간 최적화가 필요 → 최대 수를 초과하면 논리 테이블 전환 구조로 관리

많은 수의 데이터가 쌓일 때 확장성이 뛰어난 NoSQL 을 대신 사용할 수도 있겠지만, 단조 증가 ID 를 키로 사용하는 경우에는 샤딩/해싱 알고리즘의 성능 저하 가능성이 있다.

3.2. 구독자 폴링

구독자 폴링은 간단한 REST 기반 이벤트 소비 방식이다.

REST 기반에서 가장 단순한 이벤트 소비 방법은 로그 리소스를 정기적으로 조회하는 것이다.

<기본 흐름>

• 클라이언트가 일정 주기로 GET /streams/… 요청
• 응답은 이벤트 로그의 일부 (101~200번 이벤트 등)
• 하이퍼미디어 링크(HATEOAS)를 통해
  • 다음 로그 페이지
  • 이전 로그 페이지로 이동 가능

<주의점>

• 폴링 간격이 짧거나 구현이 잘못되면 네트워크 부하 유발
• 이벤트 스트림은 너무 크지 않게 고정된 범위로 분할해야 함
• 캐싱 및 읽기 시간의 간격 제한을 통해 효율성을 유지할 수 있음

부분 로그(partial log) 접근 방식

클라이언트가 이벤트 로그를 최신 상태로 유지할 수 있도록 일반 발행 URI 를 사용해 부분 로그를 제공할 수도 있다.

일반 발행 URI 사용 예시

GET /streams/policy-marketplace/current

• /current URI 는 가장 최근의 이벤트 리소스를 요청할 때 사용됨
• 응답에는 최신 이벤트 로그와 함께, 아직 읽지 않은 이전 로그로 이동할 수 있는 링크가 포함될 수 있음

예를 들어 클라이언트가 마지막으로 적용한 이벤트 ID 가 event-100 이고, /current 에서 제공하는 로그가 event-101~event-200 이라고 해보자.

1) 이전 로그로의 역방향 탐색
클라이언트는 /current 요청 결과의 HTTP 응답 헤더에서 제공되는 Link 헤더를 통해 아직 읽지 않은 이전 로그로 이동할 수 있다.

Link: </streams/policy-marketplace/previous/100-120>; rel="previous"

2) 반복적 역방향 탐색
이전 로그를 따라가면서 클라이언트는 자신이 마지막으로 읽은 이벤트가 포함된 로그를 찾을 때까지 역방향 탐색을 반복한다.
로그 ID 가 순차적이기 때문에, 범위 기반 탐색을 통해 원하는 위치에 도달할 수 있다.

3) forward 재적용
클라이언트는 마지막으로 읽은 이벤트 이후의 로그부터 차례로 이벤트를 적용하면서 최신 상태로 동기화한다.

3.3. 서버 전송 이벤트(SSE, Server-Sent Events)

서버 전송 이벤트는 서버-브라우저 간 이벤트 피드를 지원하는 것으로 잘 알려져 있지만, 여기서는 SSE 를 그런 용도로 사용하려는 것은 아니다.

SSE 는 서버 → 클라이언트 방향의 단반향 스트리밍이다.
HTTP 기반이므로 웹소켓보다 구현이 단순하다.

클라이언트는 구독을 위해 서버에 지속 연결 요청을 해야 한다.

GET /streams/policy-marketplace  
Last-Event-ID: 111

Last-Event-ID 를 통해 이전 스트림 중단 지점부터 재개 가능하다. 이는 곧 클라이언트가 스트림의 현재 위치를 기억할 책임이 있다는 것을 의미한다.
연결이 끊어지면 클라이언트가 다시 요청해서 재구독한다.

구독을 취소하려면 아래와 같은 메시지를 보낸다.

DELETE /streams/policy-marketplace

서버는 200 OK 로 응답하고, 스트림을 닫는다.

<서버-전송 이벤트의 장점>

• 실시간 이벤트 처리에 적합
• 복잡한 핸드셰이크나 프레임 처리 없이 구현 가능

<서버-전송 이벤트의 단점>

• 브라우저 호환성 이슈 (일부 오래된 브라우저에서 미지원)
• 클라이언트가 스트림 상태를 유지할 책임이 있음

4. 이벤트 주도 및 프로세스 관리

앞에서 다룬 코레오그래피가 자율적 협업 방식이라면, 여기선 오케스트레이션 방식에 대해 알아본다.
복잡한 업무 흐름을 하나의 중앙 프로세스 관리자가 주도할 때, 이벤트와 커맨드를 어떻게 설계해야 하는지 이해하는 것이 중요하다.

오케스트레이션은 업무 흐름 제어가 중요한 복잡한 프로세스에 적합하다.
메시징 인프라와 함께 사용하면 안정성과 확장성 모두 확보 가능하다.
각 서비스는 단일 책임 원칙(SRP) 에 따라 역할을 분리하고, 전체 흐름은 프로세스 관리자에게 위임한다.

오케스트레이션의 핵심은 프로세스 관리자이다.
프로세스 관리자는 전체 비즈니스 흐름을 상태를 추적하며, 각 단계의 커맨드를 명시적으로 발행한다.
아래 그림은 보험료 견적 프로세스를 오케스트레이션 방식으로 구현한 것이다.

<구성 요소>

• 프로세스 관리자
  • 전체 흐름을 추적하고 커맨드를 생성
• 이벤트
  • 각 단계의 결과를 알림
• 커맨드
  • 다음 단계로 이어지는 지시 메시지
• 도메인 서비스
  • 실제 로직을 수행하는 주체
• 메시지 버스
  • 이벤트 및 커맨드 전파 경로

1. 고객이 보험 신청을 제출 → ‘보험 신청 제출됨’ 이벤트 발생
2. 프로세스 관리자는 ‘보험 신청 제출됨’ 이벤트를 ‘리스크 평가’ 캐먼드로 변환하여 메시지 대기열에 추가
3. ‘리스크 평가’ 커맨드는 ‘리스크’ 컨텍스트로 전달되고, ‘리스크 평가 서비스’ 도메인 서비스로 디스패치됨
4. 리스크 평가 완료 후 ‘리스크 평가됨’ 이벤트가 메시지 버스 대기열에 추가됨
5. ‘리스크 평가됨’ 이벤트가 프로세스 관리자에게 전달됨
6. ‘리스크 평가됨’ 이벤트는 ‘보험료 계산’ 커맨드로 변환되어 메시지 버스 대기열에 추가됨
7. ‘보험료 계산’ 커맨드는 ‘보험료율’ 컨텍스트에 전달되고, ‘보험료율 계산 서비스’로 디스패치됨
8. 보험료율이 계산되면 ‘보험료율 계산됨’ 이벤트가 메시지 버스 대기열에 추가됨
9. ‘보험료율 계산됨’ 이벤트는 다시 프로세스 관리자에게 전달됨
10. 프로세스 관리자는 로컬에서 ‘견적 평가’ 커맨드를 직접 실행
    ‘견적 생성 서비스’ 도메인 서비스에서 ‘견적 생성됨’ 이벤트 발생
11. 이벤트를 한 번 DB 에 저장하면 메시지 버스 대기열에 다시 추가할 수 있는데 ‘견적 생성됨’ 이벤트가 이에 해당됨
    ‘견적 생성됨’ 이벤트는 DB 에 저장됨과 동시에 메시지 버스에 재전송됨 → 프로세스 종료

오케스트레이션은 최소 한 번 전송을 보장한다.

• 커맨드나 이벤트가 메시지 버스에 바로 전송되지 않고, 먼저 DB 에 저장된다.
• 메시지 전송이 실패하더라도 DB 에 기록된 상태를 기반으로 반복 재시도 가능
• 따라서 메시지 전송 실패 = 프로세스 전체 실패가 아니다.

※ 이 흐름은 10, 11 단계에서만 명시적으로 표시되었으며, 실제로는 모든 단계에 적용된다.

<오케스트레이션 장점>

• 중앙 집중 제어
  • 모든 흐름과 상태를 프로세스 관리자가 추적
• 에러 처리 용이
  • 단계별 실패 원인을 명확하게 식별 가능
• 컨텍스트 독립성 유지
  • 참여하는 컨텍스트는 자신이 맡은 일만 하면 되고, 전체 플로우는 몰라도 됨
• 동기보다 안정적인 흐름
  • 커맨드/이벤트 기반의 메시징은 서비스 간 결합도를 최소화함

5. 이벤트 소싱

DDD(1) - 이벤트 소싱 도메인 모델 패턴 을 참고하세요.

5. CQRS

DDD - CQRS 를 참고하세요.

7. 서버리스와 FaaS: 인프라 걱정없는 이벤트 기반 설계

서버리스와 FaaS 는 서버를 사용하지 않는 것이 아니라, 직접 관리하지 않아도 되는 컴퓨팅 모델이다.
서버리스와 FaaS 는 이벤트 기반 아키텍처의 최전선에서 비즈니스 로직에만 집중할 수 있는 환경을 제공한다.

서버리스에 대한 내용은 6. Serverless 를 참고하세요.

FaaS 에 대한 내용은 7. FaaS (Function as a Service) 를 참고하세요.

<서버리스와 이벤트 기반 아키텍처의 궁합>

• 트리거 기반 실행
  • REST 요청, Kafka 이벤트, DynamoDB 스트림 등 다양한 이벤트로 실행됨
• 상태 비보존
  • 상태를 서버가 갖지 않음 → 모든 상태는 입력이나 외부 저장소에 위치
• 확장성
  • 요청이 많아질수록 자동으로 함수 인스턴스 수 증가 (스케일 아웃 자동화)
• 도입 부담 낮음
  • 함수 단위로 모놀리스 → MSA → 서버리스 단계적 전환 용이

<서버리스/FaaS 도입 시 고려사항>

• Cold Start
  • 사용되지 않는 함수는 처음 실행 시 느릴 수 있음
• 상태 유지
  • 인메모리 상태 보존 불가 → 외부 DB 또는 캐시 사용 필요
• 관측성(Observability)
  • 로그, 모니터링, 트레이싱 도구 필요
• 함수 경계 설정
  • 너무 세분화하면 관리가 어려워짐 → 적절한 기능 단위로 함수 구성

서버리스는 인프라를 감추고 실행 단위만 노출하는 역할이고, FaaS 는 실제 비즈니스 로직을 수행하는 함수 단위 컴퓨팅의 역할이다.

서버리스와 FaaS 는 복잡한 이벤트 기반 시스템을 작은 단위로 나눠 민첩하게 구성할 수 있는 현대적 설계 방식이다.
특히 이벤트 소싱 + CQRS 환경에서 이벤트 핸들러 구현에 FaaS 는 매우 자연스러운 선택이 된다.

정리하며..

이벤트 기반 아키텍처를 중심으로 분산 시스템에서의 프로세스 관리, 데이터 모델링, 인프라 전략까지 단계적으로 살펴보았다.

이벤트 기반 아키텍처의 핵심 가치

• 비동기 메시징과 시간적 분리를 통해 시스템 간 결합도를 낮추고 장애 전파를 최소화
• 복잡한 비즈니스 흐름을 이벤트와 커맨드로 분리해 명확하게 관리

프로세스 관리 전략

• 단순한 분산 흐름
  • 코레오그래피: 각 서브시스템이 이벤트에 반응하여 자율적으로 처리
• 복잡한 다단계 프로세스
  • 오케스트레이션: 중앙 프로세스 관리자가 전체 흐름을 제어, 명확한 상태 추적 필요 시 사용

데이터 저장 및 조회

• 이벤트 소싱
  • 시간 흐름에 따른 엔티티 상태를 추적할 수 있도록 불변 이벤트 스트림 저장
  • 목적: 과거 상태 재구성, 감사 추적
  • 적용 시점: 상태 이력 필요 시스템
• CQRS
  • 상태 변경(Command) 과 상태 조회(Query) 를 분리하여 도메인 모델 단순화 및 조회 성능 최적화
  • 적용 시점: 복잡한 읽기 모델 필요 시

인프라 실행 및 실행 전략

• 서버리스 및 FaaS
  • 서버 관리없이 이벤트에 반응하는 함수 단위 실행으로 민첩하고 비용 효율적인 시스템 구현 가능
  • 적용 시점: 이벤트 기반 확장 환경

참고 사이트 & 함께 보면 좋은 사이트

본 포스트는 반 버논, 토마스 야스쿨라 저자의 전략적 모놀리스와 마이크로서비스를 기반으로 스터디하며 정리한 내용들입니다.

• 전략적 모놀리스와 마이크로서비스