예약된 후속 조치

한 턴 안에서 답할 수 없는 것들이 있습니다: 몇 분이 걸리는 확인, 다음 화요일을 위한 리마인더, 지금부터 6주 뒤에 열 갱신 대화. 에이전트는 그 작업을 등록하고 준비되면 답이 도착하게 할 수 있습니다.

메커니즘

도구는 턴을 막지 않습니다. 행을 쓰고 반환하므로, 고객은 지금 답을 받고 예약된 결과는 나중에 받습니다.

큐가 데이터베이스 테이블인 이유

Redis도, 브로커도 없습니다. 작업은 Postgres의 행이며, 그것은 의도적인 트레이드입니다:

• 재시작이 작업을 잃지 않습니다. 대기 중인 작업은 커밋된 행입니다. 프로세스는 실행 중에 재배포될 수 있고 폴러가 돌아오는 길에 작업을 집어 듭니다 — 지속성은 자체 실패 모드를 가진 두 번째 시스템이 아니라 이미 사용 중인 데이터 저장소에서 공짜로 옵니다.
• 운영할 것이 하나 줄어듭니다. 단일 프로세스 배포에는 폴러 루프면 충분합니다.

비용은 지연 세분성입니다: 작업은 밀리초 단위가 아니라 다음 폴에서 발동합니다. 분에서 주 단위로 측정되는 후속 조치에는 의미 있는 손실이 아닙니다.

클레임은 원자적입니다

기한이 된 작업은 FOR UPDATE SKIP LOCKED로 클레임됩니다. 폴러 하나는 그것이 필요할 수 없지만 — 지금 올바르게 쓰는 것은 나중에 두 번째 인스턴스를 실행해도 이중 전송하지 않음을 뜻합니다. 두 번 전달된 후속 조치는 겉치레 버그가 아닙니다: 고객이 같은 "갱신 기한이 됐습니다" 메시지를 두 번 받고 발신자에 대한 신뢰를 잃는 것입니다.

SKIP LOCKED는 또한 느린 작업이 그 뒤의 큐를 막지 않음을 뜻합니다. 다른 워커가 잠긴 행을 건너뛰고 다음 것을 가져갑니다.

복구

프로세스에 클레임된 뒤 그 프로세스가 죽은 작업은 그렇지 않으면 영원히 진행 중으로 앉아 있을 것입니다. 복구 패스가 멈춘 작업을 대기로 되돌려, 조용히 버려지는 대신 재시도되게 합니다.

전달은 출처를 따릅니다

결과는 플랫폼이 선택한 채널이 아니라 요청이 온 채널로 되밀려집니다. WhatsApp에서 물은 사람은 WhatsApp에서 답변받습니다. 테넌트 자신의 예약된 아웃리치 — 갱신 리마인더, 마감 독촉 — 도 당신이 설정한 주기로 같은 방식으로 동작합니다.

실제로 의미하는 것

• 에이전트가 "이건 다시 연락드릴게요"라고 말하고 실제로 그렇게 할 수 있습니다.
• 리마인더가 배포, 재시작, 크래시를 견딥니다.
• 후속 조치는 한 번 전달되고, 사람이 당신과 대화하던 곳에서 그에게 도달합니다.