스트라이프 api를 이용해 결제시스템 로그 쌓기 (with spring boot,mongodb)

 

왜 MongoDB에 따로 저장하나?

 

 

• 이벤트/웹훅은 JSON 구조가 가변적 → 문서형 DB가 유리.
• 쓰기 폭주 + 읽기 드묾: 결제 피크에 이벤트가 쏟아짐 → TTL로 자동 정리(저장비 절감).
• 장애 분석/정합성 검증(리컨실리에이션): “Stripe에선 성공인데 우리 DB는 실패?” 같은 상황에서 원본 페이로드가 생명줄.
• 멱등/재시도/비동기 처리: Outbox/Idempotency 레저(원장)로 중복 방지와 안전한 재처리.

 

MongoDB에 담으면 좋은 것 (무엇 & 왜)

 

 

• 원본 웹훅 이벤트(raw) + 서명/헤더
  • 왜: 장애 시 재현/분석, Stripe 재전송 대비, 중복 차단(이벤트 ID unique).
  • TTL: 30~180일.
• Idempotency 레저(우리 서버가 Stripe에 보낸 요청 이력)
  • 왜: 결제/환불 API 중복 호출 방지, 재시도시 동일 응답 재생성.
• Stripe 객체 스냅샷(PaymentIntent/Charge/CheckoutSession) 일부 필드
  • 왜: 대시보드 없이 빠른 확인, 리컨실리에이션 자동화(우리 주문 상태와 대조).
• 웹훅 딜리버리 로그(성공/실패/재시도 횟수, 응답코드)
  • 왜: 운영 가시성, 알람/재파이프라인 트리거 근거.
• 리컨실리에이션 결과/이상치 기록(anomalies)
  • 왜: 정합성 이슈를 누락 없이 추적(이건 TTL 없이 장기 보관 권장).
• (옵션) Product/Price 캐시(읽기 최적화)
  • 왜: 프론트 표시용. 만료 정책 또는 버전/ETag로 동기화.