개요현재 결제 서버에서는 발생하는 모든 결제 승인 건에 대해 응답(결과) 코드를 반환한다.특정 응답코드에 해당하는 승인건 발생 시 메일 알림 서비스 구축이라는 새로운 요구사항이 발생했다.최대 TPS 약 2000 에서 승인 건에 latency, Exception 전파 없는 메일 전송 기능을 설계한다. 요구사항 분석요구사항은 다음과 같다.1. 특정 응답 코드에 해당하는 승인 건 발생 시, 메일을 ‘즉시’ 발송한다.2. 메일에는 승인에 대한 데이터 (거래번호, 가맹점번호, 사유 등)을 포함한다.3. 메일 수신자는 각 사내 담당자, 백오피스 페이지를 통해 메일 주소를 설정할 수 있어야 한다. 기능 구현 상황 분석승인 로직의 최대 TPS는 약 2000각 결제수단 별 승인 로직은 Interface 를 구현(doP..
1. 개요백오피스 서비스에서 간헐적으로 OOM 에러가 발생한다. 백오피스 기능 중 방대한 크기의 금융 데이터를 Excel 형식으로 파싱하는 기능이 존재했고, Pagination 을 거치치 않은 데이터를 통한 무분별한 객체 생성으로 Heap Memory 부족 현상이 발생한다고 판단했다. 의아했던 점은 있다. Excel 로 변경하기 위해 생성된 객체는 짧은 Life Cycle 을 가지고 있기에 Garbage Collection 에 의해 지속적으로 메모리 수거가 될 것이라는 점이다.모종의 이유로 GC 가 동작하지 못하는 걸까? 원인을 분석하고 문제를 해결한 과정을 정리하려 한다. 2. 원인2025-09-17 10:12:04.231 ERROR 2080223 --- [-8650-exec-3971] o.a.c...
취업 후 3개월, 회사에도 어느 정도 적응했다고 생각되어 그동안의 회고와 앞으로의 계획에 대해 간소하게 끄적여보려 한다. 취업 전, Micro Service Architechure 의 아름다움에 매료되어 유관 교육과정에 참여했다.프로젝트 발표회 이후 감사하게도 야놀자, 카카오 등 이름 있는 기업의 여러 시니어 개발자분들께 과분한 칭찬을 많이 들었다. 덕분에 큰 자신감을 얻었고, 여러 분들께 연락처도 받으며 뜻 깊은 인연을 맺을 수 있었다. 취업 시장의 흐름에 맞춰 지원 기준을 현실적으로 조정했다. 여러 기업에 지원하며 다양한 경험을 쌓을 수 있었고, 결과도 긍정적이었다. 이 과정에서 나의 역량을 필요로 해 주는 기업은 많다는 것을 깨달았고, 다시금 현실을 객관적으로 직시할 수 있었다. (대기업에 종사하..
1. 개요데이터의 목록을 조회함에 있어 페이지네이션과 필터링은 필수불가결한 기능이다. 해당 기능을 매번 구현하다보니 Spring MVC 에서 지원하는 Pageable 객체와 매핑 값에 한계를 느껴 이를 개선하고자 한다. 개선을 통해 생성할 기능은 페이지네이션과 검색의 각 값을 검증하고 유효하지 않은 경우를 처리할 수 있도록 하는 것, 그리고 두 기능을 하나의 객체로 매핑하여 사용할 수 있는 기능이다. 결과적으로 아래와 같은 코드 형태로 간편하게 사용할 수 있는 페이징, 필터링 기능을 만든다.@GetMappingpublic ResponseEntity>> search( @SearchCondition OrderSearchCondition searchCondition, @LoginAct..
1. 개요 GitHub - hyunsb/BK-marriott-server: MSA 호텔 예약 / 선착순 쿠폰 발급 서비스MSA 호텔 예약 / 선착순 쿠폰 발급 서비스. Contribute to hyunsb/BK-marriott-server development by creating an account on GitHub.github.com MSA에서 선착순 쿠폰 발급 서비스 설계하기개요20,000 TPS 환경에서 평균 500ms의 응답속도를 보장하는쿠폰 서비스를 설계하며 고민했던 내용을 정리하려 한다. 기능은 이벤트성 선착순 쿠폰 발급과 쿠폰 관리 기능으로 나뉘며,특히 선착순hyunsb.tistory.com 선착순 쿠폰 발급 기능을 구현하며 쿠폰 발급 가능 유무를 판단하는 기능과 쿠폰 발급 및 관리에 대한..
1. 개요20,000 TPS 환경에서 평균 500ms의 응답속도를 보장하는쿠폰 서비스를 설계하며 고민했던 내용을 정리하려 한다. 기능은 이벤트성 선착순 쿠폰 발급과 쿠폰 관리 기능으로 나뉘며,특히 선착순 쿠폰 발급의 동시성 문제와 대량 트래픽을 안정적으로 처리하는 설계가 주요 도전 과제이다. 2. 쿠폰 서비스 설계쿠폰이라는 도메인은 코드의 변동 가능성, 타 서비스와의 연동 및 호출 빈도를 기준으로아래와 같이 두 기능으로 나눌 수 있었다. 선착순 쿠폰 발급 이벤트쿠폰 사용 / 관리운영 성격단기간 집중 이벤트 중심장기적이고 안정적인 기능 운영요구 사항 변경 빈도높음낮음트래픽 특성단시간에 급격한 트래픽 증가비교적 일정하고 안정적인 트래픽시스템 자원 사용량순간적으로 높은 리소스 소비일관된 자원 사용외부 시스..
1. 개요지금까지 클러스터링 인덱스(Clustering Index)는 테이블의 데이터가 디스크에 물리적으로 저장되는 순서, 정렬을 담당하는 인덱스라고 생각했다. [Real MySQL 8.0] 에서는 “물리적으로 정렬하여 저장한다.” 라는 문구가 존재했기에 오해가 생겼던 것 같다. 추가적으로 지금까지 멘토링, 면접을 진행하며 아무런 태클을 받지 못했기에 잘못된 지식이 굳어진 것 같다. 오해가 생긴 정확한 이유는 클러스터링 인덱스를 사용하면 테이블의 데이터가‘단순 배열처럼 연속된 디스크 블록에 정렬되어 저장되는 구조가 된다’ 라고 생각했기 때문이다.실제로는 B+Tree라는 자료구조를 사용하여 “논리적으로 정렬된 형태”로 저장된다. 이번에는 클러스터링 인덱스에 대해 잘못알고 있었던 지식을 재정리 해보려 한다...
1. 개요웹 서버를 개발하다보면 비슷한 형태를 가지는 코드가 반복되는 경우가 더러 있다. 이번 프로젝트에서는 JPA를 통해 낙관적 락을 간편하게 구현했는데,업데이트 쿼리 실행을 실패하면 예외(OptiimisticLockingFailureException)가 발생한다. 즉, 낙관적 락을 사용하는 모든 기능은 동시성 문제로 인해 쿼리 실행 실패 시,예외 트래킹, 디버깅, 로깅을 위해 위의 예외를 조금 더 상세하게 핸들링하는 코드가 필요하다. 예외를 핸들링하는 중복코드를 템플릿 메서드 패턴을 사용하여 가독성을 높이고, 관리 포인트를 줄여보려 한다. 2. 원인앞서 언급했듯 낙관적 락 관련 예외를 핸들링하는 코드가 다수의 메소드에 중복 선언되어 있다.public Product update(Product targ..
1. 개요이전에 DB 타입의 결정으로 조회 성능을 대폭 향상시킬 수 있었다.이번에는 페이지네이션의 방식 변경으로 조회 성능을 개선시켜보려 한다. 현재 프로젝트에는 상점을 별점, 생성일 등의 순서대로 정렬하거나 필터링하는 기능이 존재한다. 해당 기능의 결과는 페이지네이션을 통해 일부분의 데이터만 응답하게 된다. 현재는 구현이 간단한 offset 기반의 페이지네이션 방식을 사용하여 구현하고 있다. 인덱스를 생성하여 간단하게 조회 성능을 향상 시킬 수는 있지만 커서 기반 페이지네이션이라는 방식을 새로이 알게 되어 성능 비교를 해보려 한다. 2. Offset vs Cursor페이지네이션을 구현하는 대표적인 방식에는 offset 기반, cursor 기반 페이지네이션이 존재한다. 2.1. Offset 기반 ..
1. 개요 데이터베이스 테이블 PK 타입 변경에 대한 안건 · Issue #10 · IDLE-Sparta/order-management-serverContent 현재 데이터베이스 테이블의 PK 타입은 varchar, 값은 UUID 입니다. PK 타입을 varchar로 지정한 이유는 추후 PK 생성 방식의 변경을 대비하여 확장성을 고려했기 때문입니다. PK의 타입을 변경하github.com 주문관리 애플리케이션의 데이터베이스 테이블에 내부식별자와 외부식별자를 분리하는 안건에 대해 고민한 내용을 정리한다.내부, 외부 식별자의 차이는 다음과 같다.내부 식별자: 애플리케이션 서버 내부, DB 내부에서 사용하는 식별자외부 식별자: 사용자에게 보여지는 식별자 현재 데이터베이스 테이블의 PK 타입은 varchar이며..
1. 개요쿠폰의 사용 기간 정책을 저장할 방식에 대해 고민한 내용을 정리한다. 조건부 속성 문제를 DDD + Factory Method Pattern 을 사용하여DB 레벨에서는 nullable하게 application 레벨에서는 null을 허용하지 않게 설계하여 해결했다. 쿠폰 사용 기간에 대한 요구사항은 아래와 같다.1. 쿠폰은 사용할 수 있는 유효 기간을 가진다.2. 쿠폰 사용 기간 정책은 3가지로 나뉜다. 2.1. FIXED: 정해진 시작일과 종료일사이에만 사용할 수 있는 정책. 2.2. AFTER: 발급일로부터 특정일 이후까지 사용할 수 있는 정책 2.3. MIXED: 발급일로부터 특정일 이후까지, 고정된 기간 내에 사용할 수 있는 정책 2. 데이터 추출위의 요구사항을 데이터 관..
1. 문제Kafka를 사용하는 이번 프로젝트에서 데이터의 일관성을 보장하기 위해 Transactional Outbox Pattern을 적용하였다. Outbox에 새로운 데이터가 커밋되는 것을 트리거로 동작하는 Kafka 이벤트 발행 로직을 구현하기 위해 Spring Event와 @TransactionalEventListener를 사용하였다. 그러나 Spring Event를 발행하는 작업은 정상적으로 동작하였으나, @TransactionalEventListener가 이벤트를 인식하지 못하는 문제가 발생하였다. 1.1. 소스코드문제가 발생한 코드이다. ApplicationEventPublisher를 통해 DomainEventEnvelop 객체를 이벤트로 발행한다.@RequiredArgsConstructor..