Event-Driven Architecture (이벤트 기반 아키텍처)

직접 호출 (요청 기반)                    이벤트 기반
────────────────────                     ────────────────────
주문 서비스                               주문 서비스
  ├─> 재고 서비스.차감()                   └─> "주문됨" 발행 ──> [이벤트 브로커]
  ├─> 포인트 서비스.적립()                                          ├─> 재고 서비스
  ├─> 알림 서비스.발송()                                            ├─> 포인트 서비스
  └─> 배송 서비스.접수()                                            ├─> 알림 서비스
                                                                    └─> 배송 서비스
주문 서비스가 4곳을 다 알아야 한다       주문 서비스는 아무도 모른다

// 주문 서비스가 모든 후속 작업을 직접 호출한다
async placeOrder(cmd: PlaceOrderCommand) {
  const order = await this.orderRepo.save(Order.place(cmd));
  await this.inventoryClient.decrease(order.lines);  // 재고 서비스 HTTP 호출
  await this.pointClient.accrue(order.customerId);   // 포인트 서비스 HTTP 호출
  await this.notificationClient.send(order);         // 알림 서비스 HTTP 호출
  await this.shippingClient.register(order);         // 배송 서비스 HTTP 호출
  return order.id;
}

async placeOrder(cmd: PlaceOrderCommand) {
  const order = Order.place(cmd);
  await this.orderRepo.save(order);
  await this.eventPublisher.publish(new OrderPlaced(order)); // 사실만 알린다
  return order.id;
}

flowchart LR
    P1[Producer<br/>주문 서비스] -->|publish| B[[Event Broker<br/>Kafka / RabbitMQ / SNS+SQS]]
    P2[Producer<br/>결제 서비스] -->|publish| B
    B -->|subscribe| C1[Consumer<br/>재고 서비스]
    B -->|subscribe| C2[Consumer<br/>알림 서비스]
    B -->|subscribe| C3[Consumer<br/>배송 서비스]

{ "type": "OrderPlaced", "orderId": "1001" }

sequenceDiagram
    participant O as 주문 서비스
    participant B as 브로커
    participant S as 배송 서비스
    O->>B: OrderPlaced { orderId }
    B->>S: OrderPlaced { orderId }
    S->>O: GET /orders/1001 (상세 조회)
    O-->>S: 주문 상세

{
  "type": "OrderPlaced",
  "orderId": "1001",
  "customerId": "c-1",
  "shippingAddress": { "zip": "06236", "line1": "서울시 강남구 ...", "line2": "101호" },
  "lines": [{ "productId": "p-1", "quantity": 2 }],
  "totalAmount": 30000
}

메시지 큐                          이벤트 로그
┌────────────┐                     ┌─────────────────────────────────┐
│ [m3][m2][m1]──> 소비자 A         │ [e1][e2][e3][e4][e5][e6] ...    │
└────────────┘     (꺼내면 사라짐) └──▲──────────▲──────────▲────────┘
                                      소비자 A    소비자 B    소비자 C
                                      (offset 1)  (offset 3)  (offset 6)

Kafka:            topic: ordering.events
                    ├── consumer group "shipping"      (배송 서비스 인스턴스들이 나눠 처리)
                    ├── consumer group "notification"
                    └── consumer group "point"

RabbitMQ:         exchange (fanout/topic)
                    ├── queue "shipping.order-placed"
                    ├── queue "notification.order-placed"
                    └── queue "point.order-placed"

AWS:              SNS topic ──> SQS queue (구독자마다 하나씩)

// 처리한 이벤트 ID를 기록해서 중복을 막는다
@Injectable()
export class RegisterShipmentService {
  constructor(private readonly dataSource: DataSource) {}

  async execute(event: OrderPlacedV1) {
    await this.dataSource.transaction(async (tx) => {
      // 1) 이미 처리한 이벤트인지 확인 (PK 충돌로 판단)
      const inserted = await tx.query(
        `INSERT INTO processed_events (event_id, processed_at)
         VALUES ($1, now()) ON CONFLICT DO NOTHING RETURNING event_id`,
        [event.eventId],
      );
      if (inserted.length === 0) return; // 이미 처리함 → 무시

      // 2) 실제 처리 (같은 트랜잭션)
      await tx.query(
        `INSERT INTO shipments (order_id, status) VALUES ($1, 'READY')`,
        [event.data.orderId],
      );
    });
  }
}

Choreography
주문 ──OrderPlaced──> 결제 ──PaymentCompleted──> 재고 ──StockReserved──> 배송

Orchestration
           ┌──── 결제해 ────> 결제
오케스트레이터 ── 재고 잡아 ──> 재고
           └──── 배송해 ────> 배송

interface EventEnvelope<T> {
  eventId: string;
  type: string;
  occurredAt: string;
  correlationId: string; // 최초 HTTP 요청부터 이어지는 ID
  causationId?: string;  // 이 이벤트를 일으킨 이벤트 ID
  data: T;
}

flowchart TD
    A[A 작업 후 B 작업이 필요하다] --> B{B의 결과가 A의 응답에<br/>꼭 필요한가?}
    B -- 예 --> SYNC[동기 호출<br/>REST / gRPC]
    B -- 아니오 --> C{B가 실패하면<br/>A도 실패해야 하나?}
    C -- 예 --> SYNC2[동기 호출 또는<br/>같은 트랜잭션]
    C -- 아니오 --> D{B를 하는 쪽이<br/>여러 곳이거나 늘어날 수 있나?}
    D -- 예 --> EDA[이벤트 발행]
    D -- 아니오 --> E{A 응답을 빨리 줘야 하거나<br/>B가 느리고 불안정한가?}
    E -- 예 --> EDA
    E -- 아니오 --> SIMPLE[단순 호출로 충분]