2026.7.26 시스템 설계 스터디 정리

한눈에 보기

• 핵심 주제 1: 재고 차감의 동시성 제어 (append-only 원장 + 집계 테이블, 락 vs 이벤트 기반)
• 핵심 주제 2: 포인트-결제 차감 순서와 장애 시 정합성 보정 전략
• 사이드 토픽: 실제 금융 서비스 장애/사고 사례, 증권거래 시스템 설계 아이디어
• 다음 회차: 스텝을 넘어가지 않고 스텝 1·2(재고/포인트·쿠폰) 심화 + 각자 아키텍처 다이어그램 발표 + 질문 리스트 공유

1. 재고 동시성 문제 (00:00 ~ 11:00)

1-1. 기본 구조 제안: Append-only 원천 + 별도 집계 테이블

• 모든 재고 변동 이력을 append-only로 쌓아두고, 매번 이걸 집계하면 비용이 크므로 별도 집계(스냅샷) 테이블을 둔다.
• 집계 테이블은 언제든 원천 데이터 기반으로 재계산/갱신 가능해야 하지만, 품절 여부 등 비즈니스 로직이 이 값을 직접 참조하므로 정확성이 중요.

1-2. 락 전략의 실제 문제 — 데드락 경험담

• 재고 조회 → 차감 시점에 비관적 락(베타락)을 걸어 관리했으나, 요청이 몰릴 때 대기가 쌓이며 데드락 발생.
• 원인: insert(입고)와 update(차감)가 한 트랜잭션에 묶여 있고, FK가 걸려 있는 상태에서 인서트 후 업데이트를 치는 과정에서 FK 참조로 인한 shared lock이 풀리기 전에 충돌(업그레이드 락 이슈).
• 이 문제를 결국 카프카로 우회해서 해결. 단, 이는 "재고 반영이 무조건 실시간이어야 한다"는 전제하에 나온 해법.

1-3. 대안: 동시성 제어 범위를 최소화

• 문제였던 방식은 "전체 데이터 조회 → 합산 → 차감"을 통째로 락 안에 넣은 것.
• 개선안: 집계는 미리 해두고, 마지막에 원자적으로 차감하는 시점에만 락을 걸면 대기 시간을 최소화할 수 있음.
• 입고(insert)와 차감(update)을 분리:
  • 입고는 별도 스케줄러로 처리 (예: 오후 6~7시 등 정해진 입고 주기에만 집계 테이블 갱신)
  • 판매로 인한 차감은 언제든 발생하므로 업데이트만 별도로 짧게 락