TL;DR

이 글에서는 기존에 하나의 트랜잭션 안에서 동작하던 주문 생성 로직을 Spring Application Event 기반으로 분리하며, 트랜잭션 안정성과 코드 구조 개선을 동시에 달성한 과정을 정리합니다.

---

⚙️ Spring Application Event란 무엇인가

Spring Application Event는 JVM 내부 메모리에서 동작하는 in-memory 이벤트 시스템입니다.
서비스 간 강한 결합을 줄이고 후속 로직을 별도의 이벤트 핸들러로 분리하는 데 효과적입니다.
단일 서버 환경에서는 구현이 간단하고 성능도 좋아 널리 사용하는 방식입니다.

다만 구조적으로 JVM 단일 인스턴스를 기반으로 하기 때문에 몇 가지 명확한 한계가 존재합니다.

---

🚫 Spring Application Event의 구조적 한계

Spring Event는 JVM 안에서만 처리되는 메모리 기반 이벤트이기 때문에 아래와 같은 제약을 갖습니다.

🔁 멀티 인스턴스 환경에서 이벤트가 여러 번 실행되는 문제

Spring Event는 인스턴스마다 독립적으로 존재하기 때문에
동일한 이벤트가 여러 인스턴스에서 각각 실행될 수 있습니다.
“후속 처리가 단 한 번만 실행돼야 하는 로직”에는 적합하지 않습니다.

💥 장애 시 이벤트 유실

이벤트가 저장되지 않기 때문에
처리되기 전에 서버가 종료되면 해당 이벤트는 복구할 수 없습니다.
결제·정산·포인트 등 신뢰성이 중요한 영역에서 사용하기 어렵습니다.
이번 프로젝트에서는 우선 트랜잭션 분리를 목적에 두고 Spring Event를 사용했습니다.

---

🛠️ 주문 생성 트랜잭션 분리 과정

기존 주문 생성 로직은 다음과 같은 문제가 있었습니다.

• 주문 생성, 재고 차감, 포인트 차감, 쿠폰 처리, PG 요청이 모두 하나의 트랜잭션에 묶여 있음
• 후속 로직 오류(PG 요청 등)가 발생하면 주문 전체가 롤백됨
• 트랜잭션 시간이 불필요하게 길어짐
• 기능 확장 시 복잡도 증가

이를 해결하기 위해 주문 생성과 후속 처리(쿠폰, PG 요청)를 이벤트 기반으로 분리했습니다.

---

🧭 주문 처리 전략 선택 과정

모델 1 — “검증·점유 우선” (정합성 우선)

항공권/예약 시스템 등 정확성이 중요한 환경에서 사용하는 방식입니다.

모델 2 — “주문 먼저, 정합성 검증은 나중” (매출 우선)

트래픽이 높은 커머스에서 자주 사용하는 방식입니다.

---

🎯 선택한 방향: 모델 1 기반 + 후속 처리 이벤트 분리

서비스 특성상 아래 기준을 세웠습니다.

• 재고는 동시성 요구가 매우 강해 트랜잭션 내부에서 처리해야 합니다
• 쿠폰, 포인트, PG 요청은 후순위여도 무방합니다
• 주문 생성 자체는 PG 성공 여부와 관계없이 기록되어야 합니다

---

🏗️ 최종 구조

주문 생성은 본 트랜잭션에서 처리

@Transactional
public OrderInfo createOrder(CreateOrderCommand command) {
    List<Product> products = productService.getExistingProducts(
        command.orderItemRequests().stream()
            .map(CreateOrderCommand.OrderItemRequest::productId)
            .toList()
    );

    deductStock(command.orderItemRequests());

    Order order = Order.create(command.userId(), createOrderItems(command.orderItemRequests(), products));
    Order savedOrder = orderService.save(order);

    eventPublisher.publishEvent(new OrderCreatedEvent(
        savedOrder.getId(),
        command.userId(),
        command.couponId(),
        command.cardType(),
        command.cardNo()
    ));

    return OrderInfo.from(savedOrder);
}

핵심 의도

• 주문 생성과 재고 차감은 즉시 DB에 반영되어야 합니다
• 쿠폰/포인트/PG 요청은 주문 생성 이후에도 충분히 처리 가능합니다
• 후속 로직은 이벤트로 분리해 트랜잭션 영향도를 최소화했습니다

---

후속 로직은 별도 트랜잭션에서 처리

@TransactionalEventListener(phase = AFTER_COMMIT)
@Async
public void handleOrderCreated(OrderCreatedEvent event) {
    Order order = orderService.getOrder(event.orderId());

    Money originalPrice = order.getTotalPrice();
    Money finalPrice = couponService.useCouponById(
        event.couponId(),
        event.userId(),
        originalPrice
    );

    paymentService.requestPayment(event.orderId(), event.cardType(), event.cardNo(), finalPrice);

    eventPublisher.publishEvent(new OrderDataTransferEvent(
        event.orderId(),
        event.userId(),
        order.getStatus(),
        order.getTotalPrice().getAmount(),
        LocalDateTime.now(),
        "ORDER_CREATED"
    ));
}

왜 AFTER_COMMIT인가?

• 주문 생성 트랜잭션이 커밋된 이후 실행됩니다
• 후속 로직 실패가 주문 생성에 영향을 주지 않습니다
• 후속 작업만 자체적으로 롤백될 수 있습니다

---

❤️ 좋아요 집계 구조 개선 — 고빈도 이벤트 처리 최적화

좋아요 이벤트는 발생 빈도가 높아
각 요청마다 즉시 집계 테이블을 갱신하면 성능 부하가 커집니다.

이를 해결하기 위해 이벤트 기반 집계 + 디바운스 방식을 적용했습니다.

Long lastTime = lastProcessedTime.get(event.productId());
long currentTime = System.currentTimeMillis();

if (lastTime != null && (currentTime - lastTime) < debounceInterval) {
    return;
}

long actualLikeCount = likeService.getLikeCount(event.productId());
productListViewService.syncLikeCount(event.productId(), actualLikeCount);

lastProcessedTime.put(event.productId(), currentTime);

---

📌 정리

구조 개선을 통해 다음과 같은 효과를 얻었습니다.

• 주문 생성 트랜잭션이 짧아졌습니다
• 후속 작업 오류가 주문 생성에 영향을 주지 않습니다
• 좋아요와 같은 고빈도 이벤트의 처리 효율이 크게 향상되었습니다

다만 Spring Event는 근본적인 이벤트 플랫폼이 아니기 때문에
이벤트 유실·중복 처리 등 구조적 한계가 존재합니다.
이번 개편에서는 트랜잭션 분리와 코드 구조 개선을 주 목적에 두었으며,
추후 Kafka/RabbitMQ 등 MQ 기반 구조로 확장할 예정입니다.