인프런 커뮤니티 질문&답변
작성한 질문수
취소-코드느끼기 / Cancel을 별도의 스키마로 관리하는 방식의 장점
작성
·
17
·
수정됨
1
안녕하세요, 강사님.
취소 - 코드느끼기 수업의 5:00~ 부분부터
'결제', '취소'의 스키마를 분리하여 레코드를 immutable하게 다루는 상황의 예시로 결제 취소 상황을 설명하셨는데 어떤 부분에서 유리한건지 모르겠습니다.
7일 전 주문을 30일 후에 취소함
'취소'를 '결제'의 상태로 반영할 때
'결제'의 상태를 '취소'상태로 변경 - 레코드 수정 시각 갱신
취소된 '결제' 조회 시 레코드 수정 시각을 이용해야 함
'취소'를 스키마로 관리할 때
새로운 '취소' 레코드 추가
제가 이해한 상황은 '취소된 결제를 결제 id 없이 취소 시각으로 조회해야한다'는 것입니다.
취소된 결제를 결제 id 대신 취소 시각으로 찾는 경우는 어떤 상황인지, 조회를 위해 어느정도 취소시각의 범위를 특정할 수 있는 데이터가 존재할텐데 데이터가 결제 id와 분리되어 존재하는 이유가 무엇인가요?
'취소'스키마가 따로 존재해서 결제 취소가 레코드로 쌓일 때, 취소 시각으로 찾는다면 무엇이 다른건지 모르겠습니다.
'규모적으로 선택하라. 테이블이 적고 테이블 로우가 적고 접근 범위 자체를 줄일 수 있고, 이런 장점으로 보면 페이먼트 테이블을 만들어도 되는데요' 라고 말씀하신 부분도 모르겠습니다!
수업 진행하시면서 1) 각 개념의 레코드가 자신의 영역 안의 맥락으로만 수정된다, 2) '결제'의 레코드는 많고, '취소'의 레코드는 적으므로 취소 일자로 조회하는 속도 차이가 난다고 하시는 것은 이해했습니다만 앞서서 예시로 들어주신 부분은 잘 모르겠네요.
감사합니다.
답변 2
1
안녕하세요! 질문 감사드립니다!
해당 상황은 "취소 목록 조회"를 만드는 상황을 가정하고 설명하였습니다! (영상 보니 이 상황 설명이 디테일하지 않았네요!)
만약 "결제가 취소의 상태를 관리"한다면 createdAt은 취소 시점을 나타낼 수 없기 때문에 updatedAt으로 기간을 지정하고 정렬해야합니다
이 구조에서 결제 데이터가 더 많아진다고 가정하면 조회 시 updatedAt 기준으로 전체 Payment 를 조회하면서 "취소 상태"인 것을 조회해야하는 비효율이 발생하는 구조가 됩니다
(where state = 'CANCELD' and updatedAt > ?)
이렇게 되면 데이터 규모가 결제가 많고, 취소가 적다면 데이터 조회에 비효율이 발생하게 됩니다
(updatedAt 기간을 지정해도 대부분 데이터는 state = 'PAID' 일것이기 때문에, 데이터 모수 자체가 많음)
물론 고객이 느끼는 서비스 측면에서는 userId가 조건에 들어갈 것 이기 때문에 대부분 유저 기준으론 크게 문제가 없습니다만
어드민 기능으로 취소 목록을 조회해야한다고 하면 위에 말한 비효율이 더 크게 느껴집니다
물론 이 부분도 초반엔 인덱스 구성으로 어느정도 해결이 가능합니다만 개인적으로 추가적인 조회 패턴 때문에 인덱스가 이미 넉넉한데 updatedAt + state 에 대한 인덱스를 더 넣어야하는 부분은 아쉽다고 생각합니다.
* 추가적인 유리함은 강의에서 설명드린 데이터 시스템, 정산 구현 등등으로 이해해주시면 될 것 같습니다!
'규모적으로 선택하라. 테이블이 적고 테이블 로우가 적고 접근 범위 자체를 줄일 수 있고, 이런 장점으로 보면 페이먼트 테이블을 만들어도 되는데요'
이 부분은 규모에 따라 Payment 테이블에서 Cancel State 를 관리해도 된다는 의미로 설명드렸습니다!
가령 결제건이 적거나 (정기결제 기반 등), 취소가 완전히 거의 없거나, 취소와 결제가 비등한 수준이라거나, 결제 후 3일 뒤엔 취소가 불가능하다거나 (특정 산업)
이런 규모에 따라 선택이 가능하다는 것을 의미하였습니다!
핵심을 설명하느라 빠르게빠르게 넘어간 부분이라 많이 모호 할 수 있는 부분인데 잘 짚어주셨네요! 질문 감사드립니다!
모쪼록 답이 되었길 바랍니다! 감사합니다!
0
안녕하세요, 인프런 AI 인턴입니다. 백엔드해야지님!
결제와 취소 스키마를 분리하여 관리하는 것의 장점과 그에 따른 도메인 설계 방식에 대해 질문해 주셨네요. 이 방식은 데이터의 일관성과 무결성을 유지함과 동시에 다양한 비즈니스 요구사항에 대응할 수 있는 유연성을 제공합니다.
결제와 취소를 분리하여 관리하는 이유
이력을 명확하게 유지:
- 원본 결제 기록은 그대로 보존하면서, 취소 시 그에 대한 새로운 레코드를 생성함으로써 이력을 분명히 남길 수 있습니다. 이는 다양한 시점에서의 시스템 상태를 추적할 수 있게 합니다.
- 원본 결제 기록은 그대로 보존하면서, 취소 시 그에 대한 새로운 레코드를 생성함으로써 이력을 분명히 남길 수 있습니다. 이는 다양한 시점에서의 시스템 상태를 추적할 수 있게 합니다.
데이터 무결성 및 일관성:
- 기존의 결제 기록을 수정하지 않고, 별도 스키마로 취소 이력을 기록하여 원본 데이터의 무결성을 보장합니다. 취소 정보가 독립적으로 관리됨으로써 데이터 조작이 최소화됩니다.
- 기존의 결제 기록을 수정하지 않고, 별도 스키마로 취소 이력을 기록하여 원본 데이터의 무결성을 보장합니다. 취소 정보가 독립적으로 관리됨으로써 데이터 조작이 최소화됩니다.
비즈니스 요구사항의 다양성 대응:
- 비즈니스 요구가 복잡해지면서, 결제 이외에도 다양한 상태 변화가 필요할 수 있습니다. 이 경우 상태 변화를 별도의 레코드로 남기면 유연하게 대응할 수 있습니다.
- 비즈니스 요구가 복잡해지면서, 결제 이외에도 다양한 상태 변화가 필요할 수 있습니다. 이 경우 상태 변화를 별도의 레코드로 남기면 유연하게 대응할 수 있습니다.
시간 기반 분석 용이:
- ‘취소 시각’이라는 명확한 시간 데이터를 통해, 특정한 날짜나 기간(예: 특정 프로모션 기간 중 취소 많이 발생) 기반으로 데이터를 분석하기에 좋습니다.
- ‘취소 시각’이라는 명확한 시간 데이터를 통해, 특정한 날짜나 기간(예: 특정 프로모션 기간 중 취소 많이 발생) 기반으로 데이터를 분석하기에 좋습니다.
구체적인 사례 및 기존 답변
관련된 사례로는, 대규모 트랜잭션 시스템이나 정산 과정에서 취소 내역을 별도로 관리함으로써, 복잡한 비즈니스 로직을 보다 간결하고 확실하게 구현하는 경우를 들 수 있습니다. 이와 관련된 유사한 질문들이 있습니다. 참고하시려면 아래 링크를 확인해 주세요:
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
가령 결제건이 적거나 (정기결제 기반 등):
'결제' 레코드의 수가 적어 모두 둘러봐도 부담이 적음
취소와 결제가 비등한 수준이라거나:
'결제'와 '취소'의 레코드 수가 비슷하니 조회 성능의 이득이 적음
취소가 완전히 거의 없거나, 결제 후 3일 뒤엔 취소가 불가능하다거나 (특정 산업)
'취소' 레코드의 수가 적으면 적을수록 분리의 이득이 강한게 아닌가?
DB 조회 성능 측면 외에 코드나 운영적 관점이 포함된것인가?
'취소가 완전히 거의 없거나, 결제 후 3일 뒤엔 취소가 불가능하다거나 (특정 산업)' 상황에서 왜 분리하지 않는게 이득인지 잘 모르겠습니다.
DB 조회 성능 측면에서의 판단인지, 코드나 운영적 관점까지 포함한 판단인지만 말씀해주시면 제가 다시 생각해보겠습니다.