"요청이 끝난 뒤에도 중요한 일이라면 상태도 요청보다 오래 살아야 해."
요청보다 오래 살아
메모리 안 task는 process가 자기한테 하는 소문이야. 데이터베이스 행은 원래 요청과 process가 사라진 뒤에도 다른 요청이 검사할 수 있는 약속이고.
원장에 적어
jobs 행에는 id와 entry, kind, lang, status, timestamp, 최근 error가 남아. job_attempts에는 번호가 붙은 각 시도가 남고. 현재 Inkwell의 번역과 리뷰 작업에 필요한 durable evidence가 이 둘이야.
쉬운 구현의 청구서
process 안 queue는 재시작 때 받은 일을 잃고 침묵이 대기인지 실패인지 망각인지 설명하지 못해. 오래 사는 행은 기다림을 신비가 아니라 관찰 가능한 상태로 만들어.
crash를 시간선에 넣어
이 설계는 평온한 demo가 아니라 아무 순간에 process가 사라지는 시간선에서 시험해야 해. 수락 전, commit 뒤, claim 뒤, 외부 호출 뒤, 결과 저장 뒤에 각각 crash를 놓고 database가 무엇을 말하는지 적어. 사용자가 같은 요청을 다시 보내도 돈과 문장이 두 번 생기지 않아야 해.
직접 설계해
요청 수락 5초 뒤 crash가 났을 때 메모리 queue와 jobs table을 비교해. status와 timestamp, error, attempt 행을 같이 써. 복구 script가 추측으로 행을 덮지 않고 어떤 증거로 전환하는지 설명해.
관찰 가능성이 복구 가능성이야
운영자가 SQL 한 번으로 queued, running, failed, done을 구분하고 다음 안전 행동을 알 수 있어야 해. 알 수 없는 침묵을 queue라고 부르면 기다림은 이미 데이터를 잃은 거야.
운영 증거를 남겨
행 하나를 조회했을 때 왜 기다리는지와 몇 번 시도했는지, 마지막 오류가 뭔지, 다음 안전 행동이 뭔지 답할 수 있어야 해. process 로그가 사라져도 이 답이 남으면 작업은 소문이 아니라 운영 가능한 기록이 돼.
느린 외부 호출은 transaction 밖에 두고, claim과 완료만 짧고 atomic하게 만들어. 그래야 기다림이 database 전체를 잠그지 않아.