"희소한 능력을 직렬화하되 앱 전체를 묶지는 마."
희소한 lane을 좁혀
병렬이 언제나 진전은 아니야. 브레인 호출은 형제 시스템과 라우팅, 예산, 주의를 공유해. 직렬 worker 하나는 희소한 길을 드러내고 부하를 예측 가능하게 해.
브레인 앞에서 DB를 풀어
worker는 짧은 transaction에서 가장 오래된 eligible queued 행을 claim하고 running으로 바꾼 뒤 commit해. 느린 호출은 lock 밖에서 하고 완료는 두 번째 guarded transaction으로 돌아와.
직렬을 거대한 lock으로 만들지 마
모델 호출 내내 database transaction을 잡으면 관계없는 일을 막아. worker를 더 띄우면 single-consumer 계약이 깨지고 호출이 중복될 수 있어. 직렬은 거대한 lock 하나가 아니라 책임지는 consumer 하나라는 뜻이야.
crash를 시간선에 넣어
이 설계는 평온한 demo가 아니라 아무 순간에 process가 사라지는 시간선에서 시험해야 해. 수락 전, commit 뒤, claim 뒤, 외부 호출 뒤, 결과 저장 뒤에 각각 crash를 놓고 database가 무엇을 말하는지 적어. 사용자가 같은 요청을 다시 보내도 돈과 문장이 두 번 생기지 않아야 해.
직접 설계해
worker loop를 그리고 database lock을 정확히 어디서 놓는지 표시해. status와 timestamp, attempt 행을 같이 써. 복구 script가 추측으로 행을 덮지 않고 어떤 증거로 전환하는지 설명해.
관찰 가능성이 복구 가능성이야
운영자가 SQL 한 번으로 queued, running, failed, done을 구분하고 다음 안전 행동을 알 수 있어야 해. 알 수 없는 침묵을 queue라고 부르면 기다림은 이미 데이터를 잃은 거야.
운영 증거를 남겨
claim transaction은 행을 고르고 running으로 바꾼 뒤 곧바로 끝나야 해. 브레인 응답을 기다리는 동안 lock을 잡지 말고, 결과가 돌아오면 현재 status와 원문를 다시 확인하는 별도 transaction으로 착지시켜.
느린 외부 호출은 transaction 밖에 두고, claim과 완료만 짧고 atomic하게 만들어. 그래야 기다림이 database 전체를 잠그지 않아.