이번 글 요약진단편에서 찾은 문제 2(재고 100개에 300명이 삼) 를 고친다.방식재고 100개, 300명인기 상품 초당 300건락 없음300명 성공, 재고 65 남음 ❌p95 0.32초, 판매 기록 1,105건 사라짐 ❌비관적 락100명 성공, 재고 0 ✅p95 0.31초 ✅낙관적 락100명 성공, 재고 0 ✅p95 12.3초, 실패 292건 ❌원자적 UPDATE100명 성공, 재고 0 ✅p95 0.31초 ✅셋 다 재고는 맞췄다. 차이는 요청이 한 상품에 몰릴 때 났다.트랜잭션 분리 후 재측정지난 글(#02)에서 외부 결제 호출을 트랜잭션 밖으로 빼서 응답 시간을 38초에서 0.3초로 줄였다. 그때 재고 손실도 7,115건에서 24건으로 줄어서, 솔직히 "이 정도면 거의 된 거 아닌가?" 싶었다.그래..

이번 글 요약지난 글에서 찾은 문제 1(너무 느리고, 초당 31건밖에 처리 못 함) 을 고친다.시도결과커넥션 풀 10개 → 30개통과했다. 그런데 PG가 1초로 느려지자 p95 42초로 다시 무너졌다외부 결제 호출을 트랜잭션 밖으로풀 10개 그대로 p95 38초 → 0.33초. PG가 1초로 느려져도 버틴다핵심은 하나다. 커넥션을 늘리는 것보다, 커넥션을 쥐고 있는 시간을 줄이는 게 먼저다.지난 글 요약: 문제 1주문 한 건을 처리하는 동안, 외부 PG사의 결제 응답(약 0.3초)을 기다리면서도 DB 커넥션을 계속 쥐고 있었다.@Transactional ← 여기서 커넥션을 빌림 재고 차감 주문 저장 PG 결제 요청 ... 0.3초 대기 ... ← 커넥션을 쥔 채로 기다림 결제 저장 ..

이번 글 요약타임딜 주문 API를 만들고 K6로 부하를 걸어봤다. 에러는 하나도 없었는데, 실제로는 세 가지가 망가져 있었다. 문제관측한 수치1너무 느리고, 초당 처리량이 낮다p95 38초, 최대 약 31 TPS2재고가 맞지 않는다재고 100개에 300명 전원 구매 성공, 남은 재고 70개3사용자가 포기한 주문도 결제된다응답을 못 받은 요청 550건이 전부 결제 완료이번 글에서는 고치지 않는다. 무엇이, 왜 망가졌는지만 정리하고, 다음 글부터 하나씩 고친다.무엇을 만들었나타임딜 상품(재고 100개)을 오픈 시간에 많은 사람이 동시에 주문하는 상황을 가정했다. 주문 한 건의 흐름은 이렇다.POST /api/orders (하나의 @Transactional 안에서) 1. 재고 조회 → 재고 차감 2. 주..