트랜잭션 경계 설계

같은 요청도 트랜잭션 경계를 줄이면 락을 잡는 시간이 짧아집니다.

서비스 메서드 전체를 한 번에 감싸지 말고, 실제로 데이터를 바꾸는 구간만 짧게 묶어야 동시성과 실패 처리 의도가 분명해집니다.

1. 조회

읽기 전용 확인

주문 상태나 재고 수량을 확인하는 단계입니다.

readOnly=true 후보

2. 검증

비즈니스 판단

규칙 검증과 계산은 락 없이 먼저 끝낼 수 있습니다.

트랜잭션 밖 가능

3. 변경

저장 · 재고 차감

실제 DB 상태가 바뀌는 핵심 구간입니다.

짧게 묶을 지점

4. 외부 호출

HTTP · 파일 I/O

응답이 느려질 수 있으므로 락과 분리해야 합니다.

트랜잭션 밖

넓은 경계

서비스 흐름을 한 번에 묶는 경우

조회부터 외부 호출까지 한 트랜잭션 외부 응답이 지연되면 커밋도 늦어지고, 그동안 락 점유 시간이 함께 늘어납니다.

권장 경계

상태 변경이 일어나는 순간만 묶기

조회는 읽기 전용으로 분리 변경이 없다면 별도 readOnly 트랜잭션이나 비트랜잭션 조회로 충분합니다.

DB 변경만 짧게 실행 변경 후 바로 커밋해 락을 빨리 반납합니다.

외부 호출은 밖에서 실패하면 재시도나 보상 로직으로 분리합니다.

경계를 정한 뒤 함께 확인할 것

필요한 곳에만 적용 모든 메서드에 일괄로 `@Transactional`을 붙이면 불필요한 오버헤드가 생깁니다.

checked 예외 롤백 정책 기본 롤백 범위가 다를 수 있으니 프레임워크 설정을 함께 확인합니다.

운영상 의미 경계를 줄인다는 뜻은 락을 빨리 반납해 동시성 저하와 데드락 위험을 줄인다는 뜻입니다.