TIL
-
2025.11.24~ 토스 결제TIL 2025. 11. 26. 23:51
여러 가지 결제 방법.토스 개발자 문서가 잘되어 있길래, 연습 삼아 연동을 해보려 했다.시작하기부터 잘 설명되어 있다.https://docs.tosspayments.com/guides/v2/get-started잘되어 있는데, 수수료도 쌀까? 토스에서 제공해 주는 결제 위젯이라는 게 있다. 인증과 승인을 알아야 한다.인증으로 front에서 결제를 먼저 하고, 서버가 맞는지 최종 승인을 하는 것이다.문서에도 금액 위변조에 대비해 프런트에서 결제요청하기 전에 서버에 결제 금액을 저장하고 승인 시 검증하라고 한다. 카드 등록해서 쓰는 자동 결제https://docs.tosspayments.com/reference#%EC%9E%90%EB%8F%99%EA%B2%B0%EC%A0%9C 구독 서비스 등에서 카드를 등록..
-
2025.11.08~09 외부api 7 + 장부TIL 2025. 11. 8. 23:05
이어서 생각해 보니.. 장부와 주문주문의 결제와 장부의 결제는 따로 생각해야 한다.주문은 일반 유저가 결제를 진행하고, 월, 주 결제는 어드민, 시스템에 의해서 이뤄진다.주문은 결제 상태를 주문단위로 가질 수 있지만, 장부 결제는 결제 상태를 가게 단위로 관리해야 한다.장부 결제는 주체가 가게이기 때문에 하나의 외부 api가 끝나야 다음 api를 요청할 수 있도록 관리하는 것뿐이다. 분산락 + 상태를 관리하는 형태이다.그래서 상태 관리는 주문과 장부의 결제 상태 두 가지로 관리해야 이중결제를 막을 수 있다.실제 장부는 delta방식(다만 쿼리에서 last의 값을 사용)의 insert only로 관리되기 때문에 반영 순서는 상관없다. 각 상태관리를 상태머신을 코드로 관리하면 더 가독성이 나을 것 같다. 콜..
-
2025.11.06 외부api 6 + 정산TIL 2025. 11. 6. 23:14
2025.11.01~2 외부API 5외부 API를 호출하는 로직에서는 다양한 실패 상황을 고려해야 한다.생각해볼 수 있는것들이 많다.단순한 예제로 외부 호출 후 DB작업을 한다고 해보자. 여러가지를 고려할 수 있다. 응답외부 호gisungcu.tistory.com이전 글에 이어서..사실 어느 정도 끝까지 왔다고 생각했는데, 새로운 요구 사항이 있다.위의 설계는 주문당 결제의 개념이다. 일반적인 이커머스는 대부분 이럴 것이다.근데, 지금의 상황은 좀 다르다. 월결제, 주결제로 운영이 되는 업체들이 있다. 그럼 이전의 설계에서 이중 결제를 막기 위해서 주문의 결제 상태를 관리했던 것처럼, 가게의 결제를 관리해야 한다.월 누적 금액을 가게의 장부에 기록하고 있기 때문이다.(결제 대기 상태의 주문 금액을 모두 ..
-
2025.11.05 ab testTIL 2025. 11. 5. 22:11
2024.06.27 canary, AB testbliki: Canary ReleaseA canary release occurs when you roll out a new version of some software to a small subset of your user base to see if there are any problems before you make it available to everyone.martinfowler.com 매일 배포하는 팀이 되gisungcu.tistory.com과거 피쳐 토글을 활용한 ab 테스트를 구현했다.다른 회사는 어떻게 구현하는지 살펴본다.생각해보니 어떻게 구현보다 데이터로 뭘 볼지, 뭘 분석할지가 더 중요한 것 같다.a/b 테스트 목적에 따라 다르지만.예로 신..
-
2025.11.04 insert select not exists / event sourcing, current, historyTIL 2025. 11. 5. 00:11
MySQL :: MySQL 8.4 Reference Manual :: 17.7.3 Locks Set by Different SQL Statements in InnoDB17.7.3 Locks Set by Different SQL Statements in InnoDB A locking read, an UPDATE, or a DELETE generally set record locks on every index record that is scanned in the processing of an SQL statement. It does not matter whether there are WHERE conditions indev.mysql.com insert문으로 레이스컨디션을 해결할 때가 있다.insert se..
-
2025.11.01~2 외부API 5TIL 2025. 11. 1. 17:50
외부 API를 호출하는 로직에서는 다양한 실패 상황을 고려해야 한다.생각해볼 수 있는것들이 많다.단순한 예제로 외부 호출 후 DB작업을 한다고 해보자. 여러가지를 고려할 수 있다. 응답외부 호출은 성공과 실패뿐 아니라 알 수 없음의 상태도 고려해야 한다.알 수 없음은 timeout 이후 실제로는 처리되었을 가능성이 있기 때문이다.이 경우 다시 조회를 통해 결과를 확인할 수 있다.다만 timeout이 반복될 수 있으므로, 재시도 시에는 backoff를 두는 것이 적절하다. 트랜잭션 범위트랜잭션 내부에서 외부 api를 호출하는 것은 여러 자원을 점유한다.db 커넥션 풀과 애플리케이션의 스레드를 점유하고, 락을 함께 사용 중이라면 락 대기 시간이 외부 api의 응답 시간에 영향을 받는다. 호출 순서외부 api..
-
2025.10.29 외부API 4TIL 2025. 10. 29. 22:06
https://www.youtube.com/watch?v=xpwRTu47fqY이벤트 발행 실패, 혹은 발행 전 서버 다운은 발생할 수 있는 일이다.돈과 관련된 기능이면 이런 것에 대응해야한다.여기서는 배치 재처리라는 것을 언급한다.오케스트레이션 서버가 상태를 저장한다? 그리고 중단된 상태부터 배치 처리를 한다고 한다. 여기서 상태 관리를 보여준다. 지나간 상태들은 insert only형태로 기록된다. 또 적재만할 뿐 아니라 모니터링도 필요하다.ETL로 분석 DB로 옮기고, 분석 DB에서 배치를 통해 맞는지 검증한다.딱 어플리케이션이 관심사 분리가 잘되어있다고 느껴진다. 다른 부분, 메시지 발행 조차 실패할 수 있다.트랜잭션 아웃 박스등의 패턴이 있지만, 여기서는 프로듀서 DLT를 운영한다.다른 브로커로..
-
2025.10.28 외부API 3TIL 2025. 10. 28. 23:59
어제에 이어서.. 다른 서비스의 결제를 테스트해 보았다. 쿠팡, 네이버, 무신사.일단 금액은 클라이언트에서 보내지 않는다. 계좌, 카드를 사용하는 서비스는 잔액부족이면 주문이 생기지 않는다.또 쿠팡은 결제 요청을 보내고 기다리지 않는다. 결제 요청 시 return url을 던지고, 그 url을 호출해 결과를 받는다.사용자가 결과를 기다리지 않는다는 것은 알겠는데, return url이 만들어지고 그곳에 값이 채워지는 시간텀은 어떻게 아는 것일까.pg사들이 return url기능을 제공하는 것 같다. 쿠팡은 좀 더 확인 필요네이버는 팝업이 닫혀서 보지는 못했고, 무신사는 결제 요청을 보내면 response로 바로 온다. 이건 클라이언트가 결제 요청을 기다리는 형태로 개발되지 않았을까. 다른 이야기로 일단..