티켓팅

비유 ↔ 용어

아무 규칙 없음

제어 없음: 읽고 → 판단하고 → 쓰기 (read-modify-write)

줄 세우기

비관적 락 SELECT … FOR UPDATE

눈치 보고 재도전

낙관적 락: version 비교 후 갱신, 충돌하면 재시도 (최대 30회)

한 번에 처리

원자적 조건부 UPDATE … WHERE issuedCount < totalQuantity

요청 흐름

1. 브라우저 → API 버튼을 누르면 runSimulation()이 POST /coupons/simulate를 보내요. 본문은 { users: 500, quantity: 100, strategy? }예요.
2. API CouponsController.simulate가 runSimulation 관문을 먼저 지나요.
   • 다른 실험이 돌고 있으면 409
   • 쿨다운(끝나고 3초) 중이면 429 simulation_cooldown + Retry-After
   • IP당 10초에 6번을 넘으면 429 (ThrottlerGuard)
3. API → MySQL CouponStrategies.simulate가 쿠폰 sim-<전략>을 리셋하고, 가상 사용자 500명의 issue()를 동시에 던져요. 전략을 안 고르면 4개를 차례로 돌려요.
4. API → MySQL 요청마다 시작·끝 시각, 재시도 횟수, 락 대기 시간을 기록해요. 따로 연 커넥션 (connection_limit=1)이 약 25ms마다 실제 행을 읽어 스냅숏도 남겨요.
5. API → 브라우저 200 { results: [...] }로 돌려줘요. 전략마다 최종 행 상태, 요약, 스냅숏, 요청 500개 기록이 들어 있어요.
6. 브라우저 실측 타임라인을 2.5~6초로 늘여서 다시 재생해요 (useReplay).
7. 브라우저 → API 실험실의 DB 패널은 GET /coupons/:name/state?limit=10으로 실제 행을 다시 읽어요.

DB에는 이렇게 남아요

표를 이렇게 읽어요

• 제어 없음은 500명이 모두 "아직 0장"을 읽고 발급했어요. 카운터는 서로 덮어써서 issuedCount가 1에 머물렀어요 (lost update).
• 낙관적 락만 version이 100까지 올라가요. 성공한 갱신마다 1씩 올리기 때문이에요.

한계·운영에선

• 비관적 락은 모두가 한 줄로 서서, 기다리는 트랜잭션이 DB 커넥션을 붙잡아요.
• 낙관적 락은 한 행에 몰리면 재시도가 폭증하고, 30회를 넘기면 쿠폰이 남아도 실패해요.
• 원자적 UPDATE는 조건이 한 문장으로 표현될 때만 써요. 1인 1매 같은 규칙은 unique 제약과 같이 써야 해요.
• 남용 방지: 실행이 끝나면 서버 전체 3초 쿨다운, 동시 실행 1개, IP당 10초에 6번. 이 한도는 API 한 대의 메모리에 있어요.

개발자 도구로 보면

• Network 탭에는 POST /coupons/simulate 한 건만 보여요. 500명은 브라우저가 아니라 서버 안에서 동시에 돌아요.
• 응답이 커요 (전략마다 요청 기록 500개). 재생 중에는 추가 요청이 없어요.

코드·문서

1. ticketing/api.ts
2. coupons.controller.ts
3. coupon-strategies.ts · 전략 4종
4. coupon-strategies.spec.ts · 실제 MySQL에서 300명 vs 50장: 제어 없음은 초과 발급, 나머지 셋은 정확히 50장
5. lib/useReplay.ts · 재생
6. docs/handover.md · 3. 장별 흐름