파트너 소속 회원 잔액 상세 조회 기능 추가
목차
feat: 파트너 소속 회원 잔액 상세 조회 기능 추가
포인트/잔액 관련 로직은 정합성이 핵심임. 동시성 이슈와 소수점 처리를 특히 조심해야 함.
포인트 차감 순서
무상 포인트 먼저 차감 → 부족하면 유상에서 차감
(세금 처리, 환불 정책과 연관됨)
동시성 처리
-- 비관적 락으로 잔액 차감
SELECT balance FROM wallet WHERE member_sn = ? FOR UPDATE;
UPDATE wallet SET balance = balance - ? WHERE member_sn = ?;
분산 환경에서는 Redis 기반 분산 락 사용함.
충전 한도 관리
| 한도 유형 | 기준 | 초과 시 |
|---|---|---|
| 1회 최대 | 건당 금액 | 거절 |
| 일일 최대 | 24시간 누적 | 거절 |
| 월간 최대 | 월 누적 | 거절 |
사용자가 한도를 몰라서 계속 시도하는 UX를 방지하기 위해 남은 한도를 충전 화면에 표시함.
파트너 계층 구조
유통 단계가 깊어질수록 수수료 계산이 복잡해짐. 각 단계의 요율 차이가 해당 단계의 수익임.
최상위 운영사 (0%)
└── 총판 A (0.5%) → 수익 0.5%
└── 판매점 B (0.8%) → 수익 0.3%
└── 최하위 C (1.0%) → 수익 0.2%
파트너 등록 시 상위 파트너의 요율을 초과할 수 없는 검증 로직이 필요함. 초과 설정을 허용하면 마진 역전이 발생함.
작업 회고
이런 작업들이 쌓이면서 시스템이 점점 견고해진다는 걸 느낌. 당장 티가 안 나는 작업이지만 나중에 디버깅 시간을 크게 줄여줌.
코드를 작성할 때 항상 생각하는 것들:
- 미래의 나: 6개월 후에 이 코드를 다시 봤을 때 이해할 수 있는가
- 다음 개발자: 나 말고 다른 사람이 이 코드를 보면 어떻게 느낄까
- 운영 상황: 새벽 3시에 장애가 났을 때 이 코드가 문제를 빨리 파악하게 해주는가
| 좋은 코드의 기준 | 나쁜 코드의 신호 |
|---|---|
| 읽으면 의도가 바로 보임 | 주석 없으면 이해 불가 |
| 변경이 한 곳에만 영향 | 한 곳 바꾸면 여러 곳 수정 필요 |
| 테스트 작성이 자연스러움 | 테스트하려면 구조 바꿔야 함 |
끝
댓글 0
첫 댓글 달아줘.