🧐기존 결제데이터 저장 방식

1. 클라이언트(KIOSK)
   • 1분단위로 미전송된 결제데이터를 전송, 이때 무제한 전송시도
2. WAS(API 서버)
   • KIOSK에서 전송된 정보를 저장
   • 검증이나 예외처리 없이 일단 DB에 저장
   • 이후 프로시저를 통해 오류 데이터를 추출
3. 중앙 DB
   • 결제 데이터 영구 저장

다이렉트 저장방식

🛠️설계개요

1. 목표: 데이터 유실 방지, 실시간 처리, 시스템 안정성 확보, 클라이언트의 역할 감소
2. 변경내용: 기존 1분 단위 Push 방식 → 메시지 큐 기반 실시간 처리방식

메시지 큐 기반 비동기적 저장방식

📎구성요소

1. 클라이언트(KIOSK)
   • 실시간 데이터 생성 및 메시지 큐 전송.
   • 실시간 전송으로 전송 지연 최소화.
2. 로컬 DB
   • MQ 전송실패한 결제데이터 로컬 저장.
3. 메시지 큐(Message Queue)
   • AWS SQS
   • 비동기 데이터 전송.
   • 데이터 유실 방지 및 내구성 설정.
4. DLQ(Dead Letter Queue)
   • 일정횟수 이상 저장에 실패한 데이터 저장.
   • 오류 데이터 정보 저장 및 모니터링.
5. 워커 서버(Worker Server)
   • MQ의 적재량에 따라 Auto Scaling.
   • 결제 데이터를 실시간 처리.
   • 중복 데이터 검증으로 데이터 신뢰성 향상.
6. 중앙 DB
   • 결제 데이터 영구 저장.
7. 모니터링 시스템
   • 전송 성공률, 큐 적재량, 워커 서버 상태 등 실시간 관찰 가능.