[ 6주차 과제 ] 대용량 트래픽&데이터 처리 - 정리

✅ 재고 감소 (ProductService.checkAndReduceStock)
재고 차감은 가장 대표적인 경쟁 자원이므로 1순위 Spin Lock 추천

[고민]
"분산락은 파사드에서 잡아야 한다는 원칙이 있는데,
checkAndReduceStock()은 ProductService에서 하고 있다.
그럼 락을 어디서 잡는 게 맞는가?"

현재 구조
OrderFacadeImpl#createOrder() → @Transactional
→ 내부에서 productService.checkAndReduceStock() → 또 @Transactional

-> 주문 파사드 진입 전에 락을 먼저 걸어야 한다

*락 획득 / 트랜잭션 위임 / 정합성 보장 / 테스트 통과

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ
✅ 쿠폰 발급 (CouponService.issueCoupon) v
선착순 쿠폰 발급에서 중복 발급 방지 필요 Spin Lock 추천

1. 동일 유저가 여러 번 발급 시도 → 한 번만 성공
2. 여러 유저가 동시에 같은 쿠폰 발급 시도 → 재고 수량만큼만 성공 (정확한 선착순)
-> "큐 선두 진입" → "락 획득 성공" → "발급 성공" 흐름을 따라간 사용자만 선착순 발급에 성공
3. 락 획득 실패 시 → 발급되지 않음

공정 큐 = 줄 서는 순서를 지켜줌
Redis 락 = 실제 발급 시 서로 겹치지 않도록 보호

큐 선두 진입 로그는 제일 먼저 들어온 사람의 것일 수도 있고 아닐 수도 있음.
하지만 "락 시도는 반드시 선두가 먼저" 하도록 보장됨

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ
✅ 포인트 사용 및 잔액 감소 (PointService.usePoints)
포인트는 사용자 기반이라 userId 기준 락 필요 user 단위 락



ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ
✅ 주문 상태 변경 (OrderService.updateStatusToPaid)
여러 리소스를 함께 사용하는 복합 트랜잭션이므로 마지막에 적용 Lock 범위가 크므로 주의 필요