내일배움캠프 단기심화 Java - 본 캠프 Day 51

TIL - 2026.04.24

오늘 한 일

• 티켓팅 시스템 이벤트 흐름도 설계

  • 회원가입 / 로그인 / 유저 이벤트 흐름 정리
  • UserCreatedEvent, UserApprovedEvent 기반 이벤트 구조 정의
  • 비동기 처리 영역(이벤트 발행/구독) 흐름도 시각화

• 티켓팅 도메인 설계 구체화

  • 좌석 상태 관리 구조 검토
    • AVAILABLE → HOLD → RESERVED
    • HOLD → EXPIRED → AVAILABLE
  • 좌석 선점 시 TTL 정책 고민
    • 선점 ~ 결제까지 1개 TTL vs 단계별 TTL 분리 구조 비교

• 좌석/조회 트래픽 구조 고민

  • 경기 조회 / 좌석 조회 트래픽 특성 분석
  • 좌석 상태는 실시간성 요구 → 캐싱 전략 재검토
  • Redis를 캐시가 아닌 상태 저장소(인메모리 DB)로 활용하는 방향 검토

• 장애 대응 및 안정성 고민

  • Redis 장애 발생 시 대응 전략 고민
    • fallback 구조 필요성 인지
    • DB 기반 복구 or degraded mode 설계 필요

• 아키텍처 및 기술 선택 방향 정리

  • 티켓팅 시스템에서의 비동기 처리 활용 범위 고민
  • Kafka 도입 포인트 재검토 (쿠폰, 이벤트 처리 등 확장 가능성 확인)

• Redis 확장 및 장애 대응 구조 고민

  • Redis 파티셔닝(샤딩) 구조 설계
  • 특정 노드 장애 상황에서도 서비스가 동작할 수 있는 구조 고민

---

오늘 배운 점

1. 티켓팅 시스템에서 “조회”도 트래픽 핵심이다

단순히 예매(쓰기) 트래픽만 중요한 것이 아니라
경기 조회 / 좌석 조회가 훨씬 더 높은 트래픽을 유발할 수 있음

• 조회 트래픽 → 캐싱으로 해결 가능
• 좌석 상태 → 실시간성 요구 → 캐싱보다 상태 저장 전략 필요

→ 읽기/쓰기 특성에 따라 전략을 다르게 가져가야 한다

---

2. 좌석 상태는 캐시가 아니라 “상태 관리” 문제다

좌석은 단순 조회 데이터가 아니라
동시성 + 정합성 + TTL이 걸린 상태 데이터

• 캐시(Cache) → eventual consistency 허용
• 좌석 상태 → strong consistency 필요

따라서

• Redis를 캐시로 쓰기보다는
• In-Memory 상태 저장소 (락 + TTL + 원자성 보장) 로 사용하는 게 더 적절

---

3. TTL 설계는 시스템 복잡도와 직결된다

TTL 설계 방식에 따라 구조가 달라짐

• 단일 TTL
  • 구현 단순
  • 상태 관리 쉬움
• 단계별 TTL (선점 / 주문 / 결제)
  • 유연함 증가
  • 대신 상태 전이 및 관리 복잡도 상승

→ MVP 단계에서는 단순하게 시작하고
→ 이후 필요 시 분리하는 전략이 현실적

---

4. 장애 상황을 고려한 설계가 중요하다

Redis 기반 구조를 선택하면 반드시 따라오는 문제

• Redis 장애 시 전체 좌석 시스템 영향

따라서

• fallback 전략 (DB 기반 복구, 제한 모드 등)
• 장애 시 graceful degradation 설계

를 반드시 고려해야 함

---

5. Redis 파티셔닝 + 장애 허용 설계가 핵심이다

티켓팅 시스템에서는 단순 샤딩만으로는 부족하고
“노드 하나가 죽어도 서비스가 계속 돌아가는 구조”가 필요하다

1) 파티셔닝 구조

• matchId / seatId 기준으로 데이터 분산
• 여러 Redis 노드로 트래픽 분산

→ 병목 제거 + 수평 확장 가능

---

2) 문제: 특정 Redis 노드 장애

• 해당 shard에 있는 좌석 상태 조회 불가
• 예매 불가능 상태 발생

---

3) 대응 전략

(1) Replica 구조 (기본)

• Master + Replica 구성
• Master 장애 시 Replica 승격

→ Redis Sentinel / Cluster 활용

---

(2) 이중화 + 분산 설계

• 단순 샤딩 + 단일 노드 ❌
• 샤딩 + 복제(Replication) 구조 필수

예시:

• Shard 1 → Master + Replica
• Shard 2 → Master + Replica

---

(3) 장애 시 처리 전략 (중요)

• 해당 shard만 부분 장애로 처리
• 전체 서비스 다운 ❌

→ 예:

• 일부 경기만 예매 불가
• 전체 티켓팅은 유지

---

(4) fallback 전략

• Redis 장애 시
  • DB 기반 조회 (읽기만 허용)
  • 신규 선점 제한 (쓰기 제한)

→ consistency를 위해 write 차단이 현실적

---

6. 이벤트 기반 설계는 확장성을 위한 준비 단계다

현재는 단순 유저 이벤트 수준이지만

• 쿠폰 발급
• 알림 시스템
• 추천 시스템

으로 확장 가능

→ Kafka는 지금 당장 필수는 아니지만
확장 포인트를 고려한 설계는 이미 시작된 상태

---

느낀 점

오늘은 단순 기능 구현이 아니라
티켓팅 시스템의 핵심 문제인 “동시성 + 상태 관리 + 장애 대응 + 확장성”을 동시에 고민한 날이었다.

특히

• “Redis를 어떻게 쓰느냐”
• “노드 하나 죽었을 때 어떻게 할 것인가”
• “전체 장애 vs 부분 장애로 나눌 수 있는가”

이 부분을 고민하면서
단순한 기술 사용이 아니라 서비스를 운영하는 관점으로 사고가 확장된 느낌이다.

이제는 단순 구현이 아니라
장애를 견디는 구조를 설계하는 단계로 올라가고 있다.