CUD 요청의 Toss와 MySQL 처리 순서 결정

상태

승인

후보군

방안	설명
Toss 선행, MySQL 후행	Toss API 호출 성공 후 MySQL 저장/업데이트. Toss 실패 시 예외 전파, MySQL 미저장
MySQL 선행, Toss 후행 (eventual)	MySQL에 저장 후 백그라운드로 Toss에 전송
Toss 선행, MySQL 비동기	Toss 호출 후 이벤트로 MySQL 업데이트

결정

CUD 흐름: ① Toss API 호출 → ② 성공 응답 시 MySQL 저장/업데이트. @Transactional은 MySQL 업데이트 단계에만 적용한다.

결정 이유

• 주문 접수·정정·취소는 Toss에서 최종 처리되므로 Toss가 진실 원천이다.
• Toss 실패 시 MySQL에 유령 주문이 잔류하는 것을 방지한다.
• 단일 인스턴스 로컬 도구에서 동기 2-step이 충분하며, 비동기 처리는 복잡도 과잉이다.

검토 대안

방안	기각 이유
MySQL 선행, Toss 후행	Toss 실패 시 MySQL에 유령 주문 잔류. Toss가 진실 원천이므로 부적합
Toss 선행, MySQL 비동기	단일 인스턴스 로컬 도구에 이벤트 기반 비동기 처리는 복잡도 과잉

트레이드 오프

• 득: Toss가 진실 원천으로 유령 주문 발생 없음. 구현 단순.
• 실: Toss 성공·MySQL 실패 엣지 케이스(드문 네트워크 파티션)에서 불일치 가능. 이 경우 보유종목·거래내역 재조회로 일치 복구 가능.