getOrCreate / Unique? 멱등 처리 질문

Question

paymentCreator 쪽을 보니 사용자가 결제를 진행하지 않고 결제창을 닫았다가 다시 열거나 새로고침 하면 db unique 단에서 에러가 날 것 같더라구요. creator 로직에서 조회를 먼저하고 있으면 반환 없으면 생성하는 방식으로 분기문을 둔다. db unique를 타게하고 try catch 등으로 처리한다. 가독성이나 복잡도 측면에서 각각의 장단점이 있을 것 같습니다! 또한 결제창을 닫고 쿠폰이나 포인트 사용을 변경하고 다시 여는 경우도 있을 것 같은데 주문에 대해서 결제가 유니크 하나로 제한해두신 이유도 궁금합니다 이런 경우가 payment 생성 말고도 다양한 로직에서 자주 나오는 상황일 것 같은데 제미니님은 주로 어떤 스타일로 개발하시는지 궁금합니다!

제미니 · Answer

해당 부분은 취소 예제 쪽을 엮어서 표현하려다가 꼬인 것 같네요 1번의 경우는 적어주신대로 사용자의 쿠폰이나 설정이 다를 수 있기 때문에 데이터 수정이 일어나는 형태가 더 안좋아 보일 것 같습니다 2번의 경우도 로직이 지저분 할 것 같구요 핵심만 보면 주문창 -> 결제창 요청은 다양하게 생길 수 있으니 payment의 유니크를 풀어두고 조회하는 쪽에서 payment의 orderId + state 를 보는게 나을 것 같습니다 꼼꼼히 봐주셔서 감사합니다!

인프런 AI 인턴 · Answer

안녕하세요, 인프런 AI 인턴입니다. wheon06님. 결제창을 닫았다가 다시 열거나 새로고침하는 상황처럼 동일한 결제 요청이 반복될 수 있는 경우에는 조회 후 생성만으로는 동시성 문제를 완전히 막기 어렵습니다. 두 요청이 동시에 조회하면 모두 데이터가 없다고 판단할 수 있기 때문입니다. 일반적으로는 다음과 같이 역할을 나누어 고려할 수 있습니다. 먼저 조회 후 반환하는 방식은 정상적인 중복 요청을 빠르게 처리할 수 있어 가독성이 좋습니다. 하지만 동시에 여러 요청이 들어오는 경우에는 두 요청 모두 생성을 시도할 수 있으므로, DB Unique 제약조건을 최종 방어선으로 두는 것 이 안전합니다. 생성 중 Unique 충돌이 발생하면 예외를 무조건 실패로 처리하기보다, 이미 생성된 데이터를 다시 조회해 반환하는 방식으로 보완할 수 있습니다. 결제처럼 외부 PG 요청이 포함되는 경우에는 결제 키나 주문 키를 기준으로 멱등성을 보장하고, 상태를 세분화하여 중복 요청 및 실패 상황을 관리하는 것도 중요합니다. 관련된 기존 답변을 참고해 보시면 도움이 될 것 같습니다. 결제서비스 콜백 동시성문제 가능성 동시에 여러 결제 콜백이 들어올 때 포인트·쿠폰 중복 사용이나 상태 충돌을 어떻게 처리할지에 대한 질문입니다. 강의 답변에서는 검증과 예외 처리를 추가하되, 최종적으로는 낙관적 락과 수동 처리 또는 자동 보정 배치 등을 조합하는 방향을 설명하고 있습니다. 외부 API 연동 시 데이터 정합성을 고려해야 할 때.. 외부 결제 API 호출과 내부 DB 저장 사이의 불일치 문제를 다룬 질문입니다. 외부 API의 멱등성, 상태 관리, 보정 배치, 로깅과 알림 등 결제 생성 이후의 정합성을 유지하는 방법을 참고할 수 있습니다. 저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.