★★★ 정확히 이해가 안되어서 실제 내 코드를 빗대어서 정리1. 주문-결제 핵심 로직 완료PointPaymentHandler.payWithPoints(order, user) 내부에서포인트 차감주문 상태 → PAID(트랜잭션 커밋)2. 이벤트 발행 (Producer)기존 : 트랜잭션 커밋 직후(afterCommit) “커밋 직후 비동기 이벤트 발행” 파사드에 트랜잭션을 걸지 않았으므로, 핵심 로직 트랜잭션 커밋 시점을 기준으로 이벤트를 발행paymentEventPublisher.publish(new PointPaymentCompletedEvent(orderId, userId))@TransactionalEventListener(phase = AFTER_COMMIT) 로 “커밋 후”를 보장하고@Async ..

1. 기존 문제점모든 로직이 한 트랜잭션 안에서 실행포인트 차감 ▶ 결제 저장 ▶ 주문 상태 변경 ▶ 주문 정보 전달부가 작업(주문 정보 전달)이 느리거나 실패하면→ 결제 전체가 통째로 실패2. 개선 방안: 핵심 VS 부가 로직 분리핵심 로직(한 트랜잭션)유저 포인트 차감결제 정보 저장주문 상태 변경부가 로직(트랜잭션 바깥, 비동기)결제 완료 이벤트 발행 (AFTER_COMMIT)이벤트 리스너에서 비동기로 주문 정보 전달알림톡 발송 등핵심 결제에는 영향 없이, 부가 기능만 따로 실행하도록 분리3. 새로운 고민: 분산 트랜잭션여러 서비스·트랜잭션을 동시에 실행하다가 하나라도 실패하면?→ 전체를 원자적으로 롤백하는 건 거의 불가능해결 키워드:보상 트랜잭션(실패 시 역으로 처리)2PC(Two-Phase Com..

https://github.com/shinbumjun/server-java2/pull/2

1. 재고차감 피드백 - 락을 너무 오래 잡고 있어요100개 상품을 주문하면, 락 100개를 오래 잡아야 함 하나라도 실패하면 전체 실패 → 기능 제공에 악영향 락 점유 시간이 길어져서 다른 유저는 접근 자체가 안 됨 -> 피드백 반영https://github.com/shinbumjun/server-java2/pull/2/commits/16b64e0caaa8321949d143369737351ebf37f644기존에는 락과 트랜잭션이 동일한 흐름 내에 있어 책임이 분리되지 않았고,AOP 트랜잭션의 구조적 장점을 활용하지 못했다.구조를 개선하여 StockLockService에서 락만 담당하고,ProductServiceImpl에서 트랜잭션만 담당하도록 분리함으로써실질적인 AOP 기반 책임 분리 구조를 완성했다...

✅ 재고 감소 (ProductService.checkAndReduceStock) 재고 차감은 가장 대표적인 경쟁 자원이므로 1순위 Spin Lock 추천 [고민] "분산락은 파사드에서 잡아야 한다는 원칙이 있는데, checkAndReduceStock()은 ProductService에서 하고 있다. 그럼 락을 어디서 잡는 게 맞는가?" 현재 구조 OrderFacadeImpl#createOrder() → @Transactional → 내부에서 productService.checkAndReduceStock() → 또 @Transactional -> 주문 파사드 진입 전에 락을 먼저 걸어야 한다 *락 획득 / 트랜잭션 위임 / 정합성 보장 / 테스트 통과 ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ ..