업로드, 메일, 썸네일 생성처럼 느린 작업은 요청 안에서 끝내려 할수록 실패율이 올라간다. 큐는 속도보다 회복력을 위한 구조였다.

작업 idempotency
먼저 측정 가능한 기준을 정했습니다. 감으로 빠르다거나 편하다고 말하기보다, 응답 시간, 실패율, 유지보수 비용처럼 팀이 반복해서 볼 수 있는 지표를 앞에 뒀습니다.
await queue.enqueue("image.resize", {
imageId,
attempts: 0
});
재시도 간격
작게 도입한 뒤 한 주 동안 운영 데이터를 모았습니다. 예상보다 좋았던 부분은 개발 경험이었고, 예상보다 까다로웠던 부분은 예외 상황의 디버깅이었습니다.
dead letter queue
마지막 체크리스트는 단순합니다. 되돌릴 수 있는가, 실패를 관찰할 수 있는가, 팀원이 같은 결정을 다시 설명할 수 있는가. 이 세 가지가 통과되면 도입 리스크는 꽤 낮아집니다.
운영 메모
새 기술은 성능보다 운영 루틴을 먼저 흔듭니다. 알림, 로그, 롤백 경로를 같이 설계해야 오래 갑니다.
Comments
Google 계정으로 로그인 후 댓글 작성