무중단 확장 전략

---

안정적인 예약 시스템과 유연한 확장을 동시에 잡기 위한 고민과 결과물을 정리했습니다. 현재의 안정성을 유지하면서 미래의 트래픽 급증에 대비하는 무중단 확장 전략을 상세히 공유합니다.

1. IdolGlow가 택한 설계

완전한 교과서형보다 실용적인 구조

IdolGlow는 복잡한 비즈니스 로직이 외부 기술 DB, API에 오염되지 않도록 패키지 계층을 명확히 분리했습니다.

• adapter/: 입출력 접점
• application/: 유스케이스 구현 및 트랜잭션 경계 설정
• domain/: 핵심 비즈니스 규칙, 상태전이 및 불변식 정의
• infrastructure/: 기술적 세부 구현

인터페이스 중심의 의존성 역전

도메인과 애플리케이션 계층은 구체적인 구현체가 아닌 인터페이스에만 의존합니다.

행사 정보 조회 예시:
1. Domain Port: FestivalEventExternalQueryPort 인터페이스 정의
2. Application Service: 포트 인터페이스를 호출하여 비즈니스 로직 수행
3. Infrastructure Adapter: TourFestivalApiClient가 포트를 상속받아 실제 외부 API 호출 구현

설계의 실전 이점:

• 의식의 전환: "Tour API에서 가져온다"가 아니라 "행사 정보 계약을 만족한다"는 관점으로 개발합니다.
• 외부 변화 흡수: 최근 6e0bcf9 커밋에서 외부 API 응답 형식이 바뀌었을 때, 서비스 로직 수정 없이 어댑터만 수정하여 대응할 수 있었습니다.
• 테스트 용이성: 실제 API를 호출하지 않고 포트를 모킹하여 비즈니스 로직만 빠르게 검증 가능합니다.

---

2. 도메인 상태전이 + DB 락 예약 시스템의 핵심

상태 머신으로 정의된 전이 규칙

예약은 PREBOOK → PENDING → BOOKED → CANCELED 순으로 흐릅니다.
도메인 엔티티 내에서 허용되지 않는 전이 예: 취소된 건을 바로 확정 를 원천 차단합니다.

슬롯 선점의 엔티티 캡슐화

ReservationSlot 엔티티는 "누가, 언제까지 선점했는가"를 스스로 관리합니다. validateAvailability 메서드를 통해 만료된 선점은 자동으로 해제하고, 중복 선점 시도를 방지합니다.

트랜잭션 내 유스케이스 조율

1. 비관적 락으로 슬롯을 선점하여 동시 접근 차단
2. 도메인 규칙 검증 및 예약 객체 생성
3. 선점 시간 설정 및 결제 레코드 생성
4. 단일 트랜잭션 커밋으로 원자성 보장

---

3. 만료 처리를 온라인 경로에서 분리

왜 배치로 분리하는가?

결제 완료 API 안에서 만료된 예약들까지 한꺼번에 스캔하여 처리하면 응답 시간이 느려지고 시스템 부하가 커집니다.

• 나쁜 방식: API 호출 시점에 대량 스캔 → 사용자 응답 지연 5초 이상 가능
• 좋은 방식: API는 자기 할 일만 하고 즉시 응답 → 별도 배치 프로세스가 30초 주기로 만료 건 처리

배치의 설계 이점

• 온라인 경로 보호: 결제 API는 100ms 내외의 빠른 성능 유지
• 장애 격리: 배치 시스템에 일시적인 장애가 생겨도 사용자의 결제 시도는 방해받지 않음
• 유연한 정책: "만료 시간 변경" 등의 요구사항이 생겨도 배치 스케줄러 코드만 수정하면 끝

---

4. 현재 구조와 확장 포인트

현재 방식 DB 비관적 락 + 멱등성 키

현재 IdolGlow는 데이터베이스 수준의 행 잠금(SELECT ... FOR UPDATE)을 사용해 동시성을 제어합니다.
또한 벤드사 연동 시 Idempotency-Key를 사용하여 중복 결제를 원천 차단합니다.

확장 포인트 Redis 분산 락

인스턴스가 늘어나는 멀티 인스턴스 환경을 위해 DistributedLockProvider 인터페이스를 설계해 두었습니다.
현재는 로컬 JVM 메모리를 쓰지만, 설정값 한 줄만 바꾸면 Redis 기반 분산 락으로 즉시 전환 가능한 구조입니다.

---

5. 시스템 그림

전체 데이터 흐름도

6e0bcf9 커밋의 실전 가치:
외부 API의 응답이 불안정하거나 빈 값(items: "")을 줄 때, 어댑터 계층의 역직렬화 로직에서 이를 감지하고 빈 리스트로 변환합니다.
덕분에 코어 서비스와 도메인 모델은 어떤 상황에서도 안정적인 데이터를 보장받게 되었습니다.

---

지금이 최고의 타이밍 느낀점

IdolGlow의 현재 상태는 도메인이 명확하고 아키텍처가 확장을 고려해 설계되어 있습니다.

1. 실용적 Hexagonal: 외부 변화에 흔들리지 않는 코어 확보
2. 배치/온라인 분리: 안정적인 사용자 경험 제공
3. 점진적 확장성: 필요할 때만 기술을 추가할 수 있는 준비성

---

이번 작업을 통해 아키텍처는 단순히 폴더 구조를 나누는 것이 아니라, 변경과 장애의 영향을 어디까지 막을 수 있는지 결정하는 설계라는 점을 느꼈습니다.

IdolGlow에서는 외부 API 호출, 예약 상태 전이, 결제 처리, 배치 만료 처리 등을 각 계층의 책임에 맞게 분리했습니다. 덕분에 외부 API 응답 형식이 바뀌어도 어댑터 계층만 수정하면 되었고, 핵심 유스케이스와 도메인 규칙은 흔들리지 않았습니다.

또한 예약 시스템에서는 DB 락, 상태 전이, 멱등성, 배치 처리가 따로 노는 기술이 아니라 하나의 흐름으로 연결되어야 안정성이 생긴다는 점을 배웠습니다. 특히 온라인 요청에서는 빠르게 응답하고, 만료 처리 같은 작업은 배치로 분리하는 방식이 서비스 안정성에 더 현실적이었습니다.

이번 경험을 통해 좋은 설계란 처음부터 Redis, Kafka를 모두 붙이는 것이 아니라, 현재는 단순하게 운영하되 필요할 때 무중단으로 확장할 수 있는 구조를 만드는 것이라고 느꼈습니다.