-
2025.11.08~09 외부api 7 + 장부TIL 2025. 11. 8. 23:05
이어서 생각해 보니..
장부와 주문
주문의 결제와 장부의 결제는 따로 생각해야 한다.
주문은 일반 유저가 결제를 진행하고, 월, 주 결제는 어드민, 시스템에 의해서 이뤄진다.
주문은 결제 상태를 주문단위로 가질 수 있지만, 장부 결제는 결제 상태를 가게 단위로 관리해야 한다.
장부 결제는 주체가 가게이기 때문에 하나의 외부 api가 끝나야 다음 api를 요청할 수 있도록 관리하는 것뿐이다. 분산락 + 상태를 관리하는 형태이다.
그래서 상태 관리는 주문과 장부의 결제 상태 두 가지로 관리해야 이중결제를 막을 수 있다.
실제 장부는 delta방식(다만 쿼리에서 last의 값을 사용)의 insert only로 관리되기 때문에 반영 순서는 상관없다.
각 상태관리를 상태머신을 코드로 관리하면 더 가독성이 나을 것 같다.
콜백과 응답
이전 설계에서는 비즈니스 로직을 콜백에서 처리하고자 했다.
둘의 장단점을 따져본다면..
콜백에서 처리하면 결제 모듈이 붙는 프로젝트들의 비즈니스 로직을 한 곳에서 처리할 수 있다.
다만 콜백은 pg사 환경에 따라 늦을 수도, 중복, 안 올 수도 있으니 주기적으로 상태를 확인해야 한다.
응답값을 받자마자 처리하는 것은 사용자 레이턴시를 늘리는 일이다.
또 처리도중 예외가 터질 수 있기 때문에 주기적인 상태 체크, 백그라운드 워커는 필수적이다.
그렇다면 뭐가 더 나을까? 콜백처럼 한 곳에서 이후의 비즈니스로직을 관리하는 것이 낫다고 생각했다.
그러다 생각해 보면 로직적인 차이는 그리 차이 나지 않는다. 콜백도 순차적인 것이 아니니 상태체크나 필요한 락을 잡아야 경합을 피할 수 있다.
또 장애 대응도 응답으로 처리는 재처리를 고민해야 하지만 콜백은 실패에 대한 pg사의 반복 요청이 온다.
그리하여 내린 생각한 사용자 경험의 차이라고 생각한다. 응답 레이턴시를 경험하고 바로 반영된 결과를 보거나, 응답은 빠르지만 실시간 반영이 아니거나의 차이라고 생각되고, 그게 사용자 경험에 영향을 미치는지를 봐야 한다.
---
음 PaymentSession도 고려해 보자. 유니크한 키가 주문 id가 들어가 버리면 클라이언트의 요청 자체가 여러 번 올 경우 주문 id채번이 n번되고 결제 요청이 여러 번 나가, 중복결제가 된다.
2024.10.08 Duplicate Requests, Throttling Design Pattern
Rest API: How to Prevent Duplicate Requests EffectivelyThe solution to prevent duplicate requests that I want to talk about here is that when a user manipulates an API feedmedium.com 중복 request를 어떻게 처리할지에 대한 글이다.이전에
gisungcu.tistory.com
이전에도 중복 요청에 대해서 생각해 본 적이 있다.
새로고침이나 오류가 아닌 페이지 재진입으로 인한 재시도는 중복 요청을 보는 게 맞지 않다. 각기 다른 별개의 요청이다.
문제를 풀고 싶다면 주문 상태가 아닌 가게 상태로 관리하는 방법이 있겠다.
새로고침을 해서 요청하지만 이전 요청이 처리되지 않았다면 막는 것이다.
대체적으로 솔루션들이 비슷하다.
- https://velog.io/@anlee/Spring-Boot%EB%A1%9C-%EA%B5%AC%EC%B6%95%ED%95%98%EB%8A%94-%ED%9A%8C%EB%B3%B5%EB%A0%A5-%EC%9E%88%EB%8A%94Resilient-%EA%B2%B0%EC%A0%9C-%EC%8B%9C%EC%8A%A4%ED%85%9C-%EC%B9%B4%EB%93%9C-%EA%B2%B0%EC%A0%9C%EB%B6%80%ED%84%B0-%EC%A0%95%EA%B8%B0-%EA%B2%B0%EC%A0%9C-%EC%9E%A5%EC%95%A0-%EB%8C%80%EC%9D%91%EA%B9%8C%EC%A7%80
- https://velog.io/@yuhyerin/%EC%84%A4%EA%B3%84-%EA%B0%80%EC%83%81-%EB%A9%B4%EC%A0%91-%EC%82%AC%EB%A1%80%EB%A1%9C-%EB%B0%B0%EC%9A%B0%EB%8A%94-%EB%8C%80%EA%B7%9C%EB%AA%A8-%EC%8B%9C%EC%8A%A4%ED%85%9C-%EC%84%A4%EA%B3%84-%EA%B8%B0%EC%B4%88-2-11%EC%9E%A5.-%EA%B2%B0%EC%A0%9C-%EC%8B%9C%EC%8A%A4%ED%85%9C
'TIL' 카테고리의 다른 글
2025.11.24~ 토스 결제 (0) 2025.11.26 2025.11.06 외부api 6 + 정산 (0) 2025.11.06 2025.11.05 ab test (0) 2025.11.05 2025.11.04 insert select not exists / event sourcing, current, history (0) 2025.11.05 2025.11.01~2 외부API 5 (0) 2025.11.01