Quiz: Partial Failure and Reconciliation

묶음 30건을 보냈더니 200 이 왔는데 본문에는 rejected: 3 이 적혀 있다. 이 200 을 어떻게 보아야 하는가?

• 서버가 상태 코드를 잘못 쓴 것이다. 부분 실패는 207 이나 4xx 로 답해야 한다
• 요청을 받아 수락했다는 뜻이며, 요청 안의 모든 항목이 성공했다는 뜻이 아니다
• 3건은 나중에 처리된다는 뜻이므로 조금 기다렸다 다시 조회하면 된다
• 묶음 전체가 롤백됐다는 뜻이므로 30건을 통째로 다시 보내야 한다

전송 결과를 우리 쪽에 기록할 때 실패한 건만 적었다. 어떤 것을 구별할 수 없게 되는가?

• 일시적 실패와 영구적 실패
• 묶음 단위 실패와 건 단위 실패
• 아직 보내지 않은 건과 보내서 성공한 건
• 상대가 받은 건과 상대 원장에 들어간 건

30건 중 3건이 실패했다. 재전송을 어떻게 해야 하는가?

• 실패한 3건만 골라 다시 보낸다. 재시도의 단위는 묶음이 아니라 건이다
• 묶음 30건을 통째로 다시 보낸다. 상대가 중복을 막아 줄 것이다
• 묶음을 반으로 갈라 각각 다시 보내 실패한 쪽을 좁혀 나간다
• 실패한 3건을 포함한 다음 묶음에 섞어 보내 요청 수를 줄인다

실패 이유를 '다시 보낼 것' 과 '고칠 것' 으로 가르지 않으면 무슨 일이 생기는가?

• 재시도 횟수가 늘어 상대 서버의 속도 제한에 걸리고, 그 제한 때문에 정상 건까지 함께 밀린다
• 실패 건수를 이유별로 집계할 수 없게 되어 대사표에 남은 건을 적을 근거가 사라진다
• 전부 재시도하면 고칠 수 없는 건이 큐를 영원히 돌고, 아무것도 재시도하지 않으면 잠깐 걸린 건까지 사람 손으로 간다
• 상대가 같은 요청을 반복해서 받게 되어 원래는 통과했을 건까지 중복으로 판정해 돌려보낸다

대사에서 우리 기록의 성공 건수와 상대 원장의 행 수가 정확히 같았다. 더 확인할 것은?

• 없다. 건수가 같으면 같은 집합이다
• id 집합과 금액 합계. 한 건이 빠지고 다른 한 건이 두 번 들어가면 건수는 그대로다
• 요청을 보낸 시각. 양쪽의 기준 시각이 같아야 비교가 성립한다
• 묶음 수. 묶음 수가 다르면 같은 데이터가 아니다

대사 결과에 '데이터를 고쳐야 하는 8건' 이 남았다. 이 표에서 빠지면 안 되는 칸은?

• 실패한 시각. 언제부터 어긋났는지 알아야 하기 때문이다
• 재시도 횟수. 몇 번 시도했는지가 판단에 필요하기 때문이다
• 원래 요청 본문. 그대로 다시 만들 수 있어야 하기 때문이다
• 담당자. 주인이 없는 건은 아무도 고치지 않아 영원히 남기 때문이다