낸 사실을 먼저 저장해

"provider가 '완료, 청구됨' 하는 순간 그걸 적어. 오디오 건드리기 전에. 그 뒤는 다 되돌릴 수 있어도 그 사실은 아니거든."

되돌릴 수 없는 사실

유료 호출이 성공하면 아주 다른 두 종류가 일어나. 하나는 못 되돌려. 청구됐고, 이제 영원히 참인 request ID랑 비용이 생겼어. 다른 하나는 되돌릴 수 있고. 오디오를 검증하고, transcode하고, chunk를 잇고, 캐시에 쓸 텐데, 다 다시 할 수 있는 로컬 작업이거든. Bellows는 못 되돌리는 사실을 먼저 저장해. receipt, 그러니까 request ID랑 비용이랑 provider 오디오가, 어떤 후처리가 시작되기 전에 durable 저장소에 떨어져.

왜 여기선 순서가 전부냐면

다른 순서를 상상해봐. 먼저 후처리하고, 다 잘되면 그때 receipt를 저장. 이제 transcode 중 크래시가 결제했다는 흔적을 통째로 지워. 크레딧도 사라지고, provider가 만든 오디오도 사라지고, 네 시스템은 너한테 복구를 빚졌다는 것조차 몰라. receipt를 먼저 저장하면 나중 실패가 견딜 만해져. 여전히 request ID랑 비용이랑 날 provider 오디오를 쥐고 있으니까, 유료 작업을 맹목 재구매 말고 고칠 수 있어.

이건 돈을 위한 write-ahead야

데이터베이스는 이걸 늘 알았어. 대상을 바꾸기 전에 의도를 durable 로그에 써두면, 변경 도중 크래시도 복구 가능하거든. Bellows는 같은 모양을 유료 작업에 적용해. receipt가 write-ahead 기록이고, 캐시 파일이 그 변경이야. 규칙은 비싼 못-되돌릴 단계 뒤에 싼 되돌릴 단계가 오는 데면 어디든 통해. 되돌릴 수 있는 작업을 시작하기 전에 못 되돌릴 사실을 기록해.

Code

되돌릴 수 없는 사실 먼저, 되돌릴 수 있는 작업 나중·python

async def on_provider_success(job: Job, receipt: Receipt, raw_audio: bytes):
    # STEP 1 (first, ALWAYS): persist the paid fact + the raw provider bytes.
    # If anything below crashes, THIS survives -- we can repair, not re-pay.
    store.persist_receipt(job.id, receipt)          # request_id, cost, model
    lineage.save_raw(job.id, raw_audio)             # durable copy of paid audio

    # STEP 2 (after): the REVERSIBLE local work -- validate, transcode, cache.
    processed = transcode_and_validate(raw_audio)   # may fail; that's survivable
    cache.publish(job.identity, processed)

# Crash between step 1 and step 2? The receipt + raw audio are already durable.
# Reconcile rebuilds the cache file with NO new paid call.

Exercise

네가 아는 시스템에서 비싼 못-되돌릴 단계 뒤에 더 싼 되돌릴 단계가 오는 흐름을 찾아. 청구 후 영수증 이메일 발송, ID 발행 후 문서 렌더, API 호출 후 UI 갱신. 지금 저장 순서를 적어봐. 못 되돌릴 단계의 기록이 먼저 저장 안 되면, 중간 크래시가 남기는 상태를 묘사하고, write-ahead 스타일로 다시 배치해.

Hint

이렇게 물어. '못 되돌릴 단계 직후에 프로세스가 죽으면, 내 시스템이 그게 일어난 걸 알까?' 답이 나중 단계 성공에 달렸으면, durable 기록이 잘못된 자리에 있는 거야.