상시 가동형 에이전트의 백프레셔(backpressure)는 어떻게 처리하시나요?

이건 데이터 엔지니어링 문제라서 보통 에이전트가 직접 관여하지 않게 하는 게 좋습니다. 혹시 홍보하려는 제품이라도 있나요? 이미 데이터 API 통합이나 집계 기능을 제공하는 에이전트 중심의 솔루션들이 많이 나와 있습니다.

이벤트를 큐로 보지 말고 키별 최신 상태로 처리하는 게 좋습니다. 각 소스마다 워터마크를 유지하고, 복구 시 워터마크부터 데이터를 가져와 엔티티별로 병합하세요. 그러면 10개의 업데이트가 최신 상태를 반영한 하나의 작업으로 바뀝니다. 유효 기간이 지난 건 처리 지연보다 아예 안 하는 게 나으니, 그냥 건너뛰고 로그를 남기세요. 병합 후 남은 작업은 보통 양이 적어서 그냥 오래된 순서대로 처리해도 충분하며, 복잡한 우선순위 체계는 필요 없습니다.

뒤처진 상황에서 큐의 생성 시간으로 정렬하는 건 잘못된 방식입니다. 어차피 최신 이벤트가 이전 것들을 무효화하니까요. 저는 그냥 마지막 정상 워터마크보다 오래된 건 다 버리고 최신 것만 처리합니다. 재실행 시 중복 처리를 막으려면 멱등성 키(idempotency key)를 쓰고요. 제가 확인하는 유일한 상태는 'caught-up' 타임스탬프뿐입니다. 화려한 우선순위 점수 매기기는 장애가 끝났는데도 아무도 필요 없는 낡은 작업들을 처리하고 있을 때까지만 좋아 보일 뿐이죠.

저는 가장 최신의 유효한 상태를 우선시할 것 같습니다.

최신 이벤트 문제는 '상태'와 '작업'을 구분해야 해결됩니다. 같은 프로필에 대한 10번의 수정은 최신 상태를 한 번 읽는 것으로 대체 가능하지만, 10개의 고객 요청이 반드시 하나의 작업이 될 수는 없으니까요. 우선순위를 정하기 전에 이벤트 유형별로 규칙을 정의하는 게 좋습니다. 또한 무엇이 대체되었는지 기록을 남겨서, 'caught up through'가 단순히 '이전 건 다 버렸다'는 의미가 되지 않게 하세요. 복구 후에는 여전히 중요한 작업들 사이에서 마감 기한과 의존성을 기준으로 순서를 정하면 됩니다.