📦 데이터 저장 및 일관성

1️⃣ PostgreSQL 선택 이유

[비교 대상] PostgreSQL 🆚 MySQL

• ACID 완전 준수
  • PostgreSQL: 트랜잭션의 원자성 · 일관성 · 격리성 · 지속성을 완벽 보장
  • MySQL: InnoDB 사용 시 ACID 지원하나, 복잡한 동시 트랜잭션 처리에서 PostgreSQL 대비 약점
• MVCC 기반 동시성 제어
  • PostgreSQL: MVCC(Multi-Version Concurrency Control)로 읽기·쓰기 충돌 최소화 → 고부하 환경에서 안정적 처리
  • MySQL: InnoDB MVCC 제공하나, PostgreSQL의 버전 관리·가비지 컬렉션 최적화 수준에 미치지 못함
• 고급 쿼리 기능 & 확장성
  • PostgreSQL: 파티셔닝, 사용자 정의 타입 · 함수, 풍부한 인덱싱 전략 지원 → 복잡 분석·보고서 워크로드에 유리
  • MySQL: 기본 CRUD · 읽기 집약적 워크로드에 최적화되어 있으나, 복잡 조인 · 분석 쿼리에서는 한계

결론: 특정 시간에 동시 접속 폭주 및 복잡한 트랜잭션 처리 시 안정적 일관성과 효율적 동시성 제어를 제공하는 PostgreSQL을 채택했습니다.

2️⃣ id 간접 참조 선택 이유

[비교 대상] id 간접 참조 🆚 VO 매핑

• 낮은 결합도 & 유연성
  • id 간접 참조: 서비스 간 DTO(데이터 전송 객체) 변경이 있을 때 영향 최소화 → 독립 배포·확장 가능
  • VO 매핑: 공통 VO(Value Object) 스키마 변경 시 모든 서비스 수정·재배포 필요
• 단순 데이터 모델 & 유지보수성
  • id 간접 참조: PK/FK 구조로 CRUD 로직 단순화
  • VO 매핑: JOIN 연산 및 데이터 동기화 로직 추가로 복잡성 증가
• 성능 최적화
  • id 간접 참조 + Redis 캐싱: 네트워크 호출 빈도를 캐시로 완화 → 데이터 접근 성능 향상
  • VO 매핑: 빈번한 JOIN으로 DB 부하 증가, 응답 지연 우려

결론: MSA 환경에서 서비스 독립성과 단순 데이터 모델을 중시하며, 캐싱으로 성능 저하를 보완할 수 있는 id 간접 참조를 선택했습니다.

3️⃣ Outbox 패턴 선택 이유

[비교 대상] 직접 DB→Kafka 트랜잭션 🆚 Two-Phase Commit 🆚 Outbox

• 직접 트랜잭션 호출
  • 문제점: 네트워크 장애 시 메시지가 중복 전송되거나 누락될 가능성 (“반쪽 트랜잭션”)
• Two-Phase Commit (XA)
  • 문제점: 설정 복잡도·성능 오버헤드가 크며, 분산 트랜잭션 관리 어려움
• Outbox 패턴
  • 구현: 비즈니스 트랜잭션과 동일 DB 트랜잭션 내 Outbox 테이블에 이벤트 저장 → 커밋 후 별도 스케줄러/스레드가 Kafka에 발행
  • 장점:
    • 분산 트랜잭션 불필요 → 성능 저하 최소화
    • 장애 시 재시도·DLQ 처리 용이 → 메시지 정합성 보장
    • 아키텍처 단순화 → 운영·모니터링 편의

결론: 분산 트랜잭션 부담을 제거하면서도 DB와 메시지 정합성을 보장할 수 있는 Outbox 패턴을 적용했습니다.