NATS request-reply의 inbox를 재사용합니다. 늦은 응답이 새 요청에 섞이지 않게 어떤 상관 ID와 수명을 두나요?

꼬리 질문을 독립 문항으로 확장했습니다. 원래 문항에서 맥락 보기 →

잠깐, 답변을 보기 전에
먼저 내 말로 설명해 볼까요?

답변과 점검 포인트 펼치기답변 접기

구두 답변

정의를 외우기보다, 원리와 조건을 연결해 설명해 보세요.

inbox와 요청 상관 ID를 연결하고 만료·완료된 요청의 늦은 응답을 새 요청에 적용하지 않습니다. client의 inbox multiplexing 구현을 직접 추측하지 않고 API 계약을 따릅니다.

timeout으로 구독을 정리해도 responder의 작업은 계속될 수 있습니다. 변경 요청은 논리 ID로 결과를 조회합니다. 중복 응답·재접속·큰 payload·권한을 시험합니다.

이해가 드러나는 지점을 확인해 보세요.

inbox와 요청 상관 ID를 연결하고 만료·완료된 요청의 늦은 응답을 새 요청에 적용하지 않습니다. client의 inbox multiplexing 구현을 직접 추측하지 않고 API 계약을 따릅니다.
중복 응답·재접속·큰 payload·권한을 시험합니다.

놓치기 쉬운 조건과 오해를 짚어 보세요.

다음 핵심 구분을 반대로 설명하거나 성립 조건을 생략한다: inbox와 요청 상관 ID를 연결하고 만료·완료된 요청의 늦은 응답을 새 요청에 적용하지 않습니다.

하나 더 질문하며 이해의 범위를 넓혀 보세요.

득점·감점 포인트는 학습용 자기 점검 기준이며, 특정 회사의 실제 채점표가 아닙니다.

답변을 보충하는 개념·예제·슈도코드를 읽어 보세요.