Step 1. 문제 발생 (튜터님)

현재 문제 상황

<aside> ✍🏻

실무 상황에서 발생할 수 있는 문제 (현재 프로젝트를 기반으로)

</aside>

• 현재 쓰기 작업(경기장 좌석 예약)과 메시지 발송 작업이 동시에 포함되어있는 작업이 있는데, 안정성을 보장할 수 있는 수단이 보이지 않는 거 같습니다.
• 현재는 경기장의 종류 관련 데이터가 없어 서비스를 확장할 때 해당 부분이 걸릴 수 있습니다.

Step 2. 기능 명세 정의 (팀 논의 후 작성)

원인

<aside> ❓

문제가 발생한 기술적, 구조적, 또는 설계 상의 이유를 분석하여 작성합니다. 예를 들어, 데이터베이스 설계, 동시성 문제, 성능 이슈 등의 근본 원인을 명확히 서술하세요.

</aside>

1. Outbox Pattern

   • 이전에는 Saga Choreography Pattern만 적용
     • 트랜잭션 커밋 이전에 메시지를 발신하는 경우, → 트랜잭션이 롤백되어도 메시지는 외부로 전파되어 상태 불일치 발생
     • 트랜잭션 커밋 이후에 메시지를 발신하는 경우, → Commit 직후 시스템의 장애나 네트워크의 오류로 인해 메시지 유실 가능
     • 메시지 발신이 트랜잭션 경계와 완전히 동기화되지 않으므로 → 정확한 전달의 보장이 어렵고, 재시도 및 중복 방지 처리가 필요
     • 장애 상황에서 복구 로직이 복잡하고, 메시지 처리의 신뢰성 확보가 어려움
     • 시스템 간 데이터의 정합성 및 비동기 처리의 안정성 확보 불확실

2. 경기장 종류 데이터

   • 현재 경기장 엔티티의 필드는,
     • 경기장 ID, 경기장 이름, 경기장 좌석 수, 경기장 좌석들 리스트
   • 로 구성되어 있는데, 야구 경기장만을 목적으로 생긴 엔티티라 추후 확장을 고려해본다고 했을 때 어려울 수 있음

3. Outbox 테이블 읽기의 스케줄러 → MongoDB Change Stream

   • 처리 지연 발생
     • 일정 주기마다 실행되므로, 메시지 전송이 즉시 처리되지 않는다
   • 중복 처리 가능성 증가
     • 처리 중 예외가 발생하는 경우, 중복 전송되거나 누락되는 메시지가 발생할 수 있다
     • 전송 여부, 실패 여부 등의 명확한 메시지 상태를 관리하기가 어렵다
   • 트랜잭션 경계 외부에서 동작
     • 스케줄러는 트랜잭션 외부에서 동작하는데, 이는 처리 순서나 정합성을 보장하기 어렵다
   • 확장성 부족
     • 메시지 양이 증가할수록 스케줄의 주기만으로는 즉각적인 대응이 어렵다
     • 또한 대량 처리 시 병렬성을 확보하기가 어렵다
   • 리소스 낭비
     • 항상 폴링하면서 데이터베이스를 읽으므로, 처리할 메시지가 없어도 불필요한 쿼리가 수행된다 → 시스템에 불필요한 부하를 유발할 수 있다.

4. 대기열 로직에 Kafka 추가

   • Redis Sorted Set만 사용
     • Redis는 기본적으로 인메모리 기반인데, 장애가 발생하면 대기 중인 메시지가 손실될 가능성 존재
     • Redis 만으로는 메시지의 흐름을 추적하고 처리된 이력을 관리하는 것의 운영 편의성이 낮음

기능 명세

<aside> ⚙

해결을 위해 구현해야 할 기능과 예상 결과를 구체적으로 작성하세요. 어떤 데이터 입력과 출력이 필요한지, 어떤 프로세스가 수행되어야 하는지 포함합니다

</aside>