포인트 통장

비유 ↔ 용어

잔액 칸

PointWallet.balance

입출금 내역

PointEntry: 추가만 하는 원장 (append-only)

덮어쓰기

애플리케이션에서 읽고 계산해서 쓰는 read-modify-write → lost update

통장 방식

한 트랜잭션: SELECT balance … FOR UPDATE(행 잠금) → 0 미만 검사 → INSERT PointEntry → UPDATE balance = balance + ?

맞춰 보기

대사(reconciliation): balance vs SUM(PointEntry.amount)

요청 흐름

1. 브라우저 → API simulatePoints(200)이 POST /points/simulate { requests: 200 }를 보내요.
   • 다른 실험 중이면 409, 쿨다운 중이면 429 (IP당 10초 6번도 429)
2. API → MySQL PointsService.simulateBothModes가 덮어쓰기 → 통장 순서로 돌려요. 지갑마다 먼저 잔액 5,000과 opening 내역 한 줄로 리셋해요.
3. API → MySQL 요청 200개를 동시에 던져요. 적립 +100 세 번에 사용 −100 한 번 꼴이라, 정상이면 15,000이에요.
   • 덮어쓰기 applyByOverwrite: 잔액 읽기 → 내역 INSERT → balance = 읽은 값 + amount로 UPDATE (트랜잭션 없음)
   • 통장 applyByLedger: 트랜잭션 안에서 FOR UPDATE로 지갑 행 잠금 → 0 미만이면 거절 → 내역 INSERT → balance = balance + amount
4. API → MySQL 끝나면 reconcile()이 잔액 칸과 내역 합계를 비교해요. 통장 쪽은 잔액보다 100 많은 금액을 써 보고 거절되는지도 확인해요.
5. API → 브라우저 200 { results: [overwrite, ledger] }. 요청마다 읽은 시각, 쓴 시각, 본 잔액이 들어 있어요.
6. 브라우저 → API 아래 표는 GET /points/:mode/entries?limit=8로 실제 행을 읽어요.

DB에는 이렇게 남아요

표를 이렇게 읽어요

• 덮어쓰기 쪽도 내역 201줄(opening + 200)은 다 남았고 합계도 15,000이에요. 잔액 칸만 4,900이에요.
• 마지막에 쓴 요청이 옛 잔액 5,000을 읽고 100을 쓴 값을 덮어쓴 거예요. 대사가 이 어긋남(−10,100)을 잡아내요.

한계·운영에선

• 지갑 한 행을 잠그므로 한 사람에게 요청이 몰리면 줄이 길어져요 (위 시간 비교).
• 수백 개가 같은 잠금을 기다려서 트랜잭션 대기·제한 시간을 15초로 늘려 뒀어요 (기본 2초/5초).
• 실무에선 잔액 칸을 아예 두지 않고 SUM으로만 계산하거나, 잔액은 캐시로 두고 매일 밤 대사 잡으로 검증해요.

개발자 도구로 보면

• Network에는 POST /points/simulate 한 건이에요. 요청 200개는 서버 안에서 동시에 돌아요.
• 응답의 reconciliation.difference가 0이 아니면 장부와 잔액이 어긋난 거예요.

코드·문서

1. ledger/api.ts
2. points.controller.ts
3. points.service.ts · 두 방식·대사
4. ledger/lost-update.ts · "왜 15,000P가 아닐까요" 숫자
5. docs/chapters-4-6.md