Stripe가 원하는 것은 숫자 하나뿐

exe는 제품 로직 곳곳에서 결제 API를 직접 호출하는 대신, 상태 변화를 청구 가능 사실(billable facts) 로 기록하고 확정된 상태를 Stripe와 조정함 기존 구조에서는 데이터베이스 트랜잭션과 결제 API 호출이 얽혀 부분 실패, 비정상 구독 상태, 결제 거절 같은 예외가 제품 흐름까지 흔들었음 팀 좌석이 추가되면 상태를 dirty로 표시하고, 후속 워커가 비즈니스 규칙에 따라 수량을 계산해 변경된 경우에만 Stripe 구독 수량을 갱신함 결제를 분리하면 신규 팀원 온보딩이 결제 코드에 의존하지 않고, 좌석 계산 규칙을 바꿔도 초대와 가입 흐름에 영향을 주지 않음 같은 조정 구조를 활성 VM과 디스크 사용량 같은 종량제 청구와 iOS 인앱 구매에도 적용해, 제품 이벤트는 유지하면서 결제 제공자별 연동만 바꿀 수 있음 제품 흐름에서 결제 로직 분리하기 결제 로직이 일반 비즈니스 로직과 뒤섞이면 청구가 필요한 모든 핵심 경로에 관련 코드가 퍼지고, 가격 구조도 취약해져 변경하기 어려움 exe는 한 사람이 결제 지식을 독점하지 않고 누구나 관련 코드를 변경할 수 있도록 하되, 복잡한 예외는 전문 담당자가 처리하는 방식을 지향함 초기 팀 좌석 청구는 초대 수락부터 결제까지 하나의 큰 흐름으로 묶여 있었음 사용자가 초대를 수락하고 계정을 확인한 뒤 팀에 가입함 공유 VM 접근 권한과 요금제에 따른 컴퓨팅 자원을 할당받음 이 과정에서 결제 API까지 호출함 이렇게 데이터베이스 변경과 외부 API 호출을 결합하면 한쪽만 성공하는 부분 실패가 발생할 수 있음 팀 구독 상태가 비정상적일 수 있음 추가 좌석에 대한 결제가 거절될 수 있음 예외가 쌓일수록 전체 구조가 취약해짐 청구 가능 사실과 사후 조정 청구 가능 사실은 특정 상태가 바뀌었음을 나타내는 원자적 작업임 제품 로직을 먼저 실행해 자원의 새 상태를 확정함 이후 확정된 사실을 바탕으로 결제 제공자의 상태를 조정함 Stripe에는 그 상태에 도달한 과정이 아니라 최종 수량만 필요함 팀 좌석 조정 초대가 수락되면 팀 좌석 상태를 dirty로 표시함 후속 워커가 dirty 상태를 감지하고 비즈니스 규칙에 따라 좌석 증감분을 계산함 수량이 달라진 경우에만 Stripe의 구독 수량을 갱신함 팀원 추가와 결제 코드가 분리되므로 초대 흐름을 다시 작성해도 청구가 함께 깨지지 않으며, 좌석 계산 방식도 독립적으로 바꿀 수 있음 종량제 청구와 인앱 구매 같은 조정 과정은...