김둘리 개발일지

도메인 엔티티 구현이 끝나고 본격적으로 API를 구현했다. 단순해 보이는 결제 생성 API였는데 멱등성 처리와 동시성 문제까지 다루게 됐다.1. 내부 API vs 외부 API결제 생성 API를 구현하기 전에 내부 API와 외부 API의 차이를 정리했다.외부 API는 클라이언트(앱/웹)에서 Gateway를 통해 호출하는 API다.사용자 → 클라이언트 → Gateway → 결제 서비스내부 API는 서버끼리만 통신하는 API다. 클라이언트는 절대 호출하면 안 된다.Booking 서비스 → 결제 서비스 (Gateway 거치지 않음)결제 생성은 Booking 서비스가 예매 확정 시 호출하는 내부 API라서 /internal/v1/payments로 설계했다. Gateway에 등록하지 않아 외부 접근을 원천 차단한다..

개발 환경 세팅이 끝나고 본격적으로 코드 구현에 들어갔다. 공통 모듈 연동부터 도메인 엔티티 구현까지 과정에서 고민했던 것들을 정리해보려 한다.1. 공통 모듈 연동GitHub Packages 인증공통 모듈은 GitHub Packages에 배포되어 있어서 인증이 필요하다. public 패키지도 인증이 필요한 게 GitHub Packages의 특징이다.프로젝트 루트에 .env 파일을 만들어서 GitHub 인증 정보를 관리한다.GITHUB_USER=깃허브유저명GITHUB_TOKEN=ghp_xxxxxxxxxxxx토큰은 GitHub → Settings → Developer settings → Personal access tokens에서 read:packages 권한으로 발급한다..env 파일은 절대 GitHub에..

개발 환경 세팅이 끝나고 본격적인 구현 전에 프로젝트 구조를 잡았다. 패키지 구조, 공통 모듈 연동 방식, 개발 계획까지 정리해보려 한다.1. 패키지 구조팀 공통 패키지 구조 템플릿을 기반으로 결제 도메인에 맞게 구성했다.com/firstticket/payment/│├── domain/│ ├── Payment.java ← JPA Entity + Aggregate Root│ ├── PaymentHistory.java ← JPA Entity│ ├── PaymentStatus.java ← Enum│ ├── PaymentRepository.java ← interface│ ..

설계가 마무리되고 드디어 구현 단계에 들어갔다. 멀티레포 방식으로 진행하는 만큼 각 서비스별로 레포를 만들고 초기 세팅을 해야 했다. 이번 편에서는 기술 스택 선택 이유부터 GitHub 세팅까지 정리해보려 한다.1. 기술 스택Java 21Java 21을 선택한 가장 큰 이유는 가상 스레드(Virtual Thread) 지원이다.가상 스레드는 JVM 위에서 생성 및 실행되는 경량 스레드로 플랫폼 스레드보다 훨씬 가볍고 더 적은 리소스를 사용한다. 티켓팅 서비스 특성상 오픈 순간 대량의 동시 요청이 몰리는데, 가상 스레드를 활용하면 더 적은 리소스로 더 많은 요청을 처리할 수 있다.Spring Boot 3.5.13Java 21 가상 스레드를 지원하는 최신 버전이다.Spring Cloud 2025.0.1Conf..

설계가 마무리되면서 튜터님한테 피드백을 받았다. "어떤 기술을 써서 어떤 문제를 해결하는지가 보이지 않는다"는 내용이었다. 이번 편에서는 피드백을 반영해서 프로젝트 목표를 다시 정리하고 발표 멘트까지 준비한 내용을 정리한다. 1. 튜터님 피드백 반영 — 프로젝트 목표 재정리기존 목표는 기술 나열에 가까웠다. 피드백 핵심은 "어떤 기술로 어떤 문제를 해결하는지" 를 명시하라는 거였다.프로젝트 주제First Ticket — 1000명의 동시 접속에도 안정적인 예매 경험을 제공하는 MSA 기반 온라인 티켓 예매 서비스비즈니스 목표공연/전시 등 프로그램을 조회하고 티켓을 예매할 수 있는 안정적이고 끊김 없는 서비스 제공좌석 있는 공연은 실시간 좌석 선택, 좌석 없는 공연은 선착순 예매 방식 지원1000명이 동시..

1. 도메인 모델 다이어그램최종 결제 도메인 모델 구성이다.Payment (Aggregate Root)결제 도메인의 핵심 엔티티다. bookingId, userId는 다른 도메인의 ID를 참조만 한다. 직접 조인하거나 객체를 들고 있지 않고 UUID만 가지고 있어서 도메인 간 결합도를 낮췄다.payment_key는 토스가 결제 승인 완료 후에 돌려주는 값이라 요청 시점에는 NULL이고, confirm 단계에서 UPDATE로 채워진다.PaymentHistory (Entity)Payment의 상태가 바뀔 때마다 이력을 쌓는 엔티티다. tossRawResponse에 토스 원본 응답 JSON을 저장해서 디버깅이나 감사 목적으로 활용한다.TossPaymentsPort (ACL/Interface)ACL(Anti-C..

설계가 다 끝났다고 생각했는데 검토 과정에서 치명적인 문제를 발견했다. Kafka 비동기 구조에서 발생하는 레이스 컨디션이었고, 이를 해결하면서 산출물이 연달아 바뀌었다. 이번 편에서는 그 과정을 정리해보려 한다.1. 레이스 컨디션 발견기존 설계에서 결제 레코드 생성 흐름은 이랬다.Booking → Kafka(payment.requested) → 결제 서버 → 결제 레코드 생성Kafka가 비동기라서 이벤트 발행 후 결제 레코드 생성까지 수ms ~ 수백ms의 지연이 생긴다. 문제는 그 사이에 사용자가 토스 결제창에서 결제를 완료하고 confirm을 호출하면 결제 레코드가 아직 없어서 오류가 난다는 거다. payment.requested 발행 ↓ (수ms ~ 수백ms 지연) 결..

1편에서 결제 도메인 산출물을 다 뽑았는데, 팀 회의 하다 보니 수정할 게 꽤 생겼다. 카프카 기반 구조로 바뀌면서 API 명세서, 시퀀스 다이어그램, 컨텍스트 맵이 다 바뀌었고, 아웃박스 패턴이랑 인프라 설계까지 진행했다. 이번 편에서 그 내용을 정리해보려 한다.1. API 명세서 수정 — 결제 요청 흐름 변경원래는 클라이언트가 직접 POST /api/v1/payments를 호출하는 구조였는데, 팀이랑 얘기하다 보니 예매 도메인에서 Kafka로 결제 요청을 보내는 구조로 바뀌었다.변경 전클라이언트가 직접 결제 요청 API 호출변경 후예매 확정 → Booking이 payment.requested 이벤트 발행 → Payment가 구독해서 결제 레코드 생성그래서 POST /api/v1/payments는 외부..

설계 단계에서 컨텍스트 맵, 테이블 명세서, API 명세서, ERD, 시퀀스 다이어그램 총 5가지 산출물을 뽑아야 했는데 이걸 정리해보려고 한다. 실제 결제는 없이 토스페이먼츠 연동만 구현하는 방향으로 진행했다. 전체 산출물 목록컨텍스트 맵 (Context Map)테이블 명세서API 명세서ERD시퀀스 다이어그램1. 컨텍스트 맵 (Context Map)컨텍스트 맵은 결제 도메인이 다른 도메인들과 어떻게 관계를 맺는지 보여주는 다이어그램이다.결제 도메인의 주요 관계를 정리하면 이렇다.연관 도메인관계 유형설명예매(Booking)Customer/Supplier (Upstream)예매 확정 시 결제 요청 트리거. Payment는 Booking의 Downstream사용자(User)Shared Kernel / ACL..

1. 결제 도메인 설계 방향결제 도메인은 단순히 “결제 성공 여부”만 관리하는 것이 아니라, 상태 변화와 외부 PG 연동까지 포함하는 핵심 도메인이다.이번 프로젝트에서는 다음 기준으로 설계했다.결제 상태는 명확한 상태값으로 관리한다상태 변경 이력은 별도로 관리한다외부 PG(토스)와의 통신은 서버에서 검증한다서비스 간 통신은 이벤트 기반으로 분리한다2. Payment / PaymentHistory 구조결제 도메인은 하나의 애그리거트로 구성된다.Payment: 현재 상태를 관리하는 Aggregate RootPaymentHistory: 상태 변경 이력을 기록하는 엔티티역할 구분Payment는 “현재 상태”를 의미한다.PENDING / SUCCESS / FAILED / REFUNDED PaymentHistory..