ADR-002 소진성 자원 reseed = 멱등 synthetic SQL/Redis 복원
상태
채택 (2026-07-03)
맥락
B2C 3000TPS 상시 쓰기(30%)로 슬롯·재고·좌석이 고갈되면 이후 쓰기가 409로 수렴해 일주기 곡선이 붕괴한다(FR-3). NFR은 “재충전이 관측 대상 앱에 순간 부하 스파이크를 유발하지 않을 것 + synthetic 데이터로만 동작”을 요구한다. 전용 admin reseed API는 없고(실측), 복원 수단은 도메인별 개별 경로뿐이다 — Stock.restore(가산)·POST /api/goods-seller/products/{id}/stock/restore(GOODS_SELLER)·POST /bookings/{id}/cancel·POST /events/{id}/seats/release·좌석 락 300s TTL. 기존 부하 시드는 qa/load/seeds/*.sql 멱등 복원 SQL 관례를 이미 따른다.
결정
reseed 컨테이너가 synthetic ID 범위에만 멱등 절대값 복원 SQL/Redis 명령을 10분 주기로, 청크·jitter로 윈도 내 분산 실행한다. stocks.quantity baseline reset, synthetic 예약·주문 정리(슬롯 해방), 좌석 락은 300s TTL 자연 만료에 위임. 기존 도메인 복원 엔드포인트 호출은 폴백(도메인 불변식이 꼭 필요한 극단)으로만.
근거
- 멱등 절대 복원 → 반복 실행에도 드리프트 없음(가산 restore는 무한 증가 위험).
- 앱 요청 부하 0 — DB/Redis 직접 복원이라 관측 대상 앱에 reseed 트래픽이 실리지 않음(NFR 측정 왜곡 방지). 엔드포인트 호출 방식은 reseed 요청 자체가 측정에 섞임.
- 기존
seeds/*.sql(owner_id=1 더미·stock 9999 upsert) 관례와 정합 → 재사용·리뷰 용이. - 애플리케이션 코드·Flyway 마이그레이션 0 — 무변경 원칙·Single Writer 준수.
- “기존 도메인 메서드 활용”은 복원 의미(재고 quantity·슬롯 가용·좌석 TTL)를 그대로 활용하는 것으로 충족. 실행 수단만 synthetic SQL.
결과
- reseed는 synthetic 범위 밖 데이터를 절대 write하지 않음(테스트로 강제).
- 윈도 분산으로 순간 write 스파이크 없음(NFR).
- 미채택: 도메인 엔드포인트 호출 reseed(드리프트·인증·측정 왜곡), 앱 admin reseed API 신설(코드 변경·prod 상주).