예약 프로젝트

프로젝트 소개 예약, 결제, 리워드 지급 등 동시성 이슈가 발생할 수 있는 도메인을 직접 구현하며, 상황에 적합한 동시성 전략을 적용하는 것을 목표로 진행한 프로젝트입니다. 예약 생성 시 조건부 UPDATE( 비어 있는 좌석만 원자적으로 선점 )로 동일 좌석에 대한 중복 예약을 방지하고, 멱등성 키( DB unique 제약 기반 선점 )를 적용하여 동일...

예약 예약 진행 플로우 예약은 좌석 선택 단계(최대 5분)와 결제 단계(최대 5분)로 나뉩니다. 사용자가 좌석을 선택한 뒤 결제 화면으로 이동하면, 최대 5분 - 좌석 선택 소요 시간 + 결제 시간(최대 5분) 동안 선택한 좌석을 보호해야 합니다. 만약 이 기간 동안 DB 락을 유지한다면, 트랜잭션과 커넥션을 오랫동안 점유하게 되어 커넥션 풀이 쉽게 ...

예약 프로젝트에서 회원 가입 시 사용자 ID의 형식 유효성을 검사하는 로직을 구현하였습니다. ID 하나만을 검증 대상으로 삼는 단순한 구조였기 때문에, Kotlin의 value class를 활용하여 구현하였습니다. value class를 사용한 이유 value c

Outbox로 비즈니스 트랜잭션과 메일 발송을 분리하고, 발송 과정은 선점 → 발송 → 정리로 분리하여 SMTP 발송 중 DB 커넥션을 점유하지 않도록 설계했습니다. 또한 attempt_count와 dead 상태를 통해 반복 실패한 메일을 격리하여 무한 재시도를 방지했

예약 로직에 분산 락을 적용하여 좌석 중복 예약을 방지하고, 멱등성을 적용하여 동일 요청이 반복되더라도 예약이 한 건만 생성되고 동일한 응답이 반환되도록 구현했습니다. 이를 k6를 사용하여 검증하고자 합니다.k6 스크립트는 깃허브의 reserve-race-test.js

대기열 시스템은 대기열과 참가열로 구성되며, 참가열에 진입한 사용자에게만 예약 요청 권한이 부여됩니다. 대기열과 예약 시스템이 분리된 구조이므로, 예약 시스템에 대한 동시성 테스트를 통해 처리 가능한 최대 부하를 산정한 뒤, 이를 기준으로 참가열의 최대 수용량( max

계좌에 1000원이 있을 때, 1000원을 입금하려는 요청과 2000원을 뺴려는 요청이 동시에 들어오는 상황즉, 어느 데이터를 읽거나 쓸 때, 처리 순서에 따라 결과가 잘못되는 문제이러한 동시성 문제를 어떻게 해결할 것인가 ?동시에 실행되는 여러 개의 트랜잭션이 작업을

시스템 성능 향상 시키기 위해 멀티코어 시스템을 사용하여 여러 프로세스가 동시에 실행되게 하지만 이러한 환경에서는 하나의 공유 자원을 여러 프로세스가 동시에 접근하려 할 때 문제가 발생할 수 있음예를 들어, 한 프로세스가 자원을 사용하고 있는 동안 다른 프로세스가 동시

멱등성 동일한 연산을 여러 번 수행하더라도 서버의 최종 상태가 처음 한 번 수행했을 때와 동일하게 유지되는 성질을 의미합니다. 멱등성은 서버의 상태가 동일함을 의미하며, 매 요청마다 반환되는 HTTP 응답 코드나 결과 메시지까지 완전히 동일해야 함을 의미하는 것은 아닙니다. ex ) DELETE 요청 시 첫 번째는 200 OK, 두 번째는 404 No...

코틀린에서 QueryDSL를 사용하기 위해서는 반드시 kapt를 사용해야 합니다.kapt( Kotlin Annotation Processing Tool )왜 kapt를 사용해야할까 ?QueryDSL은 컴파일 타임에 @Entity 클래스를 기반으로 Q클래스를 자동 생성하