저장할 것과 조회할 것

작업을 큐에 넣고 나중에 처리하는 구조에서 작업 레코드에 무엇을 담을지가 문제였다. 값을 복사해 담는 방식과 식별자만 담고 실행 시점에 조회하는 방식이 있었다.

Open Table of contents

스냅샷과 참조

앞의 것은 작업을 만든 시점의 값을 레코드에 복사해 둔다. 뒤의 것은 식별자만 담고 실행할 때 현재 값을 조회한다.

담는 내용의 차이로 보이지만 성질이 완전히 다르다. 무엇을 담느냐가 아니라 어느 시점의 값으로 처리하느냐를 정하는 선택이었다.

값이 중간에 바뀌면 스냅샷은 옛 값으로 처리하고 참조는 새 값으로 처리한다. 주문 시점의 가격으로 결제해야 하는 일이라면 스냅샷이 맞다.

보내는 시점의 현재 설정을 반영해야 하는 일이라면 참조가 맞다. 어느 쪽이 좋은 방식인지가 아니라 그 업무가 어느 시점을 뜻하느냐가 답을 정한다.

이 작업은 외부에 현재 상태를 반영하는 것이라 값이 바뀌었으면 바뀐 값으로 나가는 것이 맞았다. 그래서 실행 시점에 조회하게 했다.

이 선택의 효과가 나중에 드러났는데 설정을 바꾼 뒤 재전송이 간단해졌다. 스냅샷이었으면 기존 작업을 지우고 다시 만들어야 하는데 참조라서 작업 하나만 새로 만들면 새 값으로 나갔다.

참조에는 함정이 있어서 실행 시점에 대상이 없을 수 있다. 스냅샷이면 값이 레코드에 있으니 생기지 않는 문제다.

실패로 처리할지 기본값으로 진행할지 자동 생성할지를 골라야 했다. 이 도메인에서는 설정이 없으면 기본 설정을 만드는 편이 못 보내는 것보다 나아서 자동 생성으로 갔고 그 사실을 문서에 적었다.

자동 생성을 넣으면 사전 확인 항목이 하나 생긴다. 대량 작업을 돌리기 전에 매핑이 없는 대상이 몇 건인지 세어 봐야 한다.

많으면 자동 생성이 대량으로 돌고 그것은 예상하지 못한 부하가 된다. 같은 값인데 대상에 따라 이쪽에서 조회하는 경우와 다른 계층이 스스로 조회하는 경우로 갈려서 경로별로 어디서 조회하는지도 표로 정리해 뒀다.