[백엔드 모의면접] 중복 결제는 어떻게 막을까?
안녕하세요.
인프랩에서 모의면접 서비스를 개발/운영하고 있는 약풍이라고 해요.
최근에 SNS에오늘의 면접질문컨텐츠를 연재하고 있었는데,인프런에도 해당 컨텐츠를 업로드 해달라는 요청들이 있었어요.
오늘부터 주기적으로 이곳에도 5분내로 읽을 수 있는 면접질문을 하나씩 업로드하려고 해요.
재미있게 읽어주시면 감사하겠습니다🙇
오늘의 백엔드 질문
결제 API에 동일한 요청이 두 번 들어왔을 때, 중복 결제를 어떻게 막으시겠어요?
이력서/포트폴리오에 결제나 주문,쿠폰 발급이 있으면 나올 수 있는 질문이에요.
실제로 이런 일이 발생할 수 있을까? 싶기도 하지만, 실무에서 종종 발생하는 이슈에요.
이 질문은 결제 요청이 한 번만 온다는 전제로 코드를 짰는지,
혹은 결제 요청이 여러번 전송되어도 한 번만 처리되도록 로직을 작성했는지 검증하는 질문이에요.
답변 키포인트
멱등키(Idempotency-Key)를 누가 만들고 어디에 저장할지
멱등키에 DB 유니크 제약을 걸어 최종 방어선을 설정했는지
처리중과 완료 상태를 구분해 저장하고, 완료면 이전 응답을 그대로 돌려주는 것
재시도와 원요청이 동시에 처리될 때의 경합
외부 PG 응답이 유실됐을 때의 대사(reconciliation)
"버튼 비활성화"처리 만으로는 아쉬운 이유
중복 결제를 이야기할 때 "프론트에서 버튼을 비활성화한다"에서 끝나면 아쉬운 답변이에요.
버튼은 언제든 클라이언트에 의해 조작될 수 있어서,실제 방어 로직은 서버와 DB에 있어야 하거든요.
같은 키로 들어온 두 번째 요청을 새 결제가 아니라 이미 처리한 요청의 조회로 취급하는 구조인지,두 요청이 동시에 들어와도 유니크 제약이 하나를 확실히 막아주는지를 같이 설명할 수 있게 준비하는 게 좋아요.
면접에서는
면접에서 이 질문을 받았다면 "재시도 자체를 없앨 수는 없으니, 요청이 여러 번 들어와도 결과는 한 번만 처리한다"라는 식으로 답변을 시작하면 좋아요.
그다음에는 아래 순서로 이어서 설명하면 돼요.
주문마다 멱등키를 만들고, 그 키에 유니크 제약을 건다.
두 번째 요청은 새로 처리하지 않고 저장된 결과를 반환한다.
PG 응답 유실처럼 서버가 통제할 수 없는 경우에는, 주기적인 대사 과정으로 데이터를 보정한다.
이러한 중복 요청 처리 방안은 결제 외에도 다양한 적용할 수 있어요.
쿠폰 발급,포인트 적립,Kafka의 at-least-once 소비 이슈 모두 연관된 질문으로 나올 수 있어요.
꼬리질문
다음의 꼬리질문도 생각해보세요.
멱등키는 클라이언트와 서버 중 어디에서 생성하는 것이 좋을까요?
DB에서 주문을 조회 후 없으면 insert 하는 방식에는 어떤 문제가 있나요?
같은 멱등키의 요청 두 개가 동시에 들어오면 두 번째 요청에는 어떤 응답을 주시겠어요?
첫 요청이 아직 처리 중일 때 들어온 재시도는 대기시키는 것과 에러를 반환하는 것 중 어느 쪽이 낫나요?
PG에는 결제가 성공했는데 우리 서버가 응답을 받지 못했다면 어떻게 복구하나요?
AI 모의면접으로
나의 면접 스킬을 체크해보세요
프론트엔드,백엔드,FDE 기술면접부터 문화면접까지,
개발자 면접 준비를 실전처럼 연습해 보세요.
답변 0