김둘리 개발일지

MSA 환경에서 분산 트랜잭션의 정합성을 보장하기 위해 코레오그래피 기반 사가 패턴과 보상 트랜잭션을 구현했다.1. 문제 - 분산 트랜잭션모놀리식 아키텍처에서는 하나의 DB 트랜잭션으로 모든 작업을 묶을 수 있다.하나의 트랜잭션→ 결제 처리→ 예매 확정→ 성공 시 commit, 실패 시 rollbackMSA에서는 각 서비스가 독립적인 DB를 가져서 하나의 트랜잭션으로 묶을 수 없다.Payment DB ─┐ ├── 두 DB를 하나의 트랜잭션으로 묶을 수 없음 💀Booking DB ─┘이런 상황에서 정합성을 보장하려면 어떻게 해야 할까?2. 사가 패턴이란?사가 패턴은 MSA에서 분산 트랜잭션을 처리하는 패턴이다.각 서비스의 로컬 트랜잭션을 순서대로 실행하고 실패 시 보상 트랜잭션으로 이..

환불 처리 완료 시 Booking 서비스가 예매 취소 상태로 변경할 수 있도록 payment.refund.completed 이벤트 발행을 추가했다.1. 배경기존에는 환불 처리가 완료되어도 Booking 서비스에 알리는 방법이 없었다.Payment → 환불 처리 완료 (REFUNDED)→ Booking은 모름→ 예매 상태가 취소로 변경되지 않음 💀Booking 서비스가 예매 취소 처리를 할 수 있도록 이벤트를 발행해야 했다.2. 이벤트 명세서 작성팀과 함께 이벤트 명세서를 작성했다.결제 관련 이벤트를 명확하게 분리했다.payment.completed → 결제 승인 완료 시 발행payment.failed → 결제 최종 실패 시 발행payment.refund.completed → 환불..

ECS Fargate 배포를 위한 Docker 이미지 빌드 파일 작성과 GitHub Actions CI 파이프라인을 구성했다.1. 왜 Docker를 사용하나?기존 → 각자 IntelliJ에서 직접 실행→ "내 컴에서는 되는데?" 문제 발생→ 환경마다 다른 결과Docker → 어느 컴퓨터에서도 동일한 환경→ 배포 시 EC2, ECS에 이미지로 올림→ 환경 차이 없음2. Dockerfile - 멀티 스테이지 빌드단순히 jar를 복사하는 방식 대신 멀티 스테이지 빌드를 적용했다.# ===== Stage 1: Build =====FROM eclipse-temurin:21-jdk-alpine AS builderWORKDIR /appCOPY gradlew .COPY gradle gradleCOPY build.gra..

PENDING 상태로 방치된 결제를 자동으로 FINAL_FAILED 처리하는 스케줄러를 구현했다.1. 문제사용자가 결제창을 열고 결제를 하지 않으면 PENDING 상태로 계속 남아있는 문제가 있었다.결제 생성 → PENDING→ 사용자가 결제창 닫음→ PENDING 상태로 방치 💀→ Booking은 예매 확정도 취소도 못 함2. 해결 방법1분마다 만료된 PENDING 결제를 찾아서 자동으로 FINAL_FAILED 처리한다.스케줄러 1분마다 실행→ requestedAt이 retryTtlSeconds(300초) 이전인 PENDING 결제 조회→ FINAL_FAILED 상태로 변경→ payment.failed 이벤트 발행→ Booking이 수신해서 예매 취소 + 좌석 선점 해제3. PaymentReposit..

코드 리팩토링을 통해 내부 API 응답 구조 개선, 환경별 URL 분리, 환불 멱등성 처리를 적용했다.1. 내부 호출 APIResponse 제거기존에는 내부 서비스 간 통신에도 ApiResponse로 감싸서 응답했다.// 기존@PostMappingpublic ResponseEntity> createPayment( @RequestBody @Valid PaymentCreateRequest request) { return ApiResponse.success(PaymentSuccessCode.PAYMENT_CREATED, response);}Booking 서비스가 Feign Client로 호출할 때 ApiResponse를 벗겨서 써야 하는 번거로움이 있었다.내부 API는 바로 데이터만 반환하도록 변경..

Booking 서비스에서 환불 이벤트를 발행하면 Payment 서비스가 수신해서 토스 취소 요청 및 REFUNDED 상태로 변경한다.1. 배경환불이 필요한 케이스는 두 가지다.케이스 1 - 사용자가 직접 예매 취소케이스 2 - 좌석 선점 시간 만료두 케이스 모두 Booking 서비스가 booking.payment.refund 토픽으로 이벤트를 발행한다. Payment 서비스는 이걸 수신해서 환불 처리한다.2. Booking 담당자와 Payload 협의{ "paymentId": "결제 UUID", "bookingId": "예매 UUID", "userId": "사용자 UUID", "reason": "환불 사유"}paymentId를 포함해서 보내기로 했다. Booking 서비스에서 결제 ..

프로젝트는 수행하는 것보다 "설명할 수 있는 상태로 만드는 것"이 더 중요하다. 결제 서비스를 개발하면서 사용한 기술들을 정리하고 왜 그 기술을 선택했는지, 어떤 문제를 어떻게 해결했는지 구조화했다.1. 핵심 기술 키워드토스페이먼츠 결제 연동무엇을 했는가서버 승인 방식으로 클라이언트 직접 승인을 차단하고 결제 금액 대조 검증으로 위변조를 탐지했다.bookingId UNIQUE 제약과 DataIntegrityViolationException catch로 중복 결제를 원천 차단했다.왜 서버 승인 방식인가클라이언트 승인 방식은 사용자가 금액을 조작하거나 직접 토스 승인 API를 호출할 수 있는 보안 취약점이 있다.서버에서 승인하면 DB에 저장된 금액과 토스 응답 금액을 대조 검증할 수 있어 위변조를 즉시 탐지..

결제 실패 이벤트를 언제 발행해야 하는지에 대한 정책을 팀과 논의했다. 선점 시간 내 재시도 가능 정책으로 인해 FINAL_FAILED 상태가 추가됐다.1. 문제 발견처음 구현에서는 토스 검증 실패 시 바로 payment.failed 이벤트를 발행했다.// 토스 응답 검증 실패 시payment.fail(300);Events.publish("payment.failed", ...); // 바로 발행코드래빗 리뷰:payment.failed를 발행한 뒤 같은 결제를 다시 SUCCESS로 전이할 수 있습니다.2. 팀 논의 - 재시도 정책팀에서 정한 정책은 이랬다.좌석 선점 시간(10분) 내에는 결제 재시도 가능선점 시간이 만료되면 재시도 불가Booking 담당자 확인:결제 실패 == 재시도까지 다 하고 실패한 경..

토스 결제 승인이 실패했을 때 Booking 서비스가 예매 취소 및 좌석 선점 해제를 할 수 있도록 payment.failed 이벤트 발행을 추가했다.1. 배경Booking 담당자의 요청이었다.결제 실패 이벤트 수신 후 예매 취소 및 좌석 선점 해제 처리가 필요합니다.2. PaymentFailedPayload 추가public record PaymentFailedPayload( UUID paymentId, UUID bookingId, UUID userId, String reason) { public static PaymentFailedPayload from(Payment payment, String reason) { return new P..

[팀프로젝트] MSA 기반 티켓팅 프로그램 - 전체 레이어 테스트 코드 작성MSA 환경에서 결제 서비스의 신뢰성을 높이기 위해Domain, Application, Infrastructure, Presentation 전 레이어에 테스트 코드를 작성했다.1. 테스트 전략각 레이어별로 다른 테스트 방식을 사용했다.Domain → JUnit5 단위 테스트 (순수 자바, 외부 의존성 없음)Application → JUnit5 + Mockito (의존성 Mocking)Infrastructure → @DataJpaTest (JPA 레이어 슬라이스 테스트)Presentation → @WebMvcTest + Rest Docs (Controller 슬라이스 테스트)2. Domain 테스트도메인 객체..