제공자가 경계다

마지막 단계가 우리 것이 아니기 때문입니다.

이 경계를 인정하는 것이 설계의 출발점입니다. 도착을 보장하려 하지 말고, 넘기는 것까지를 확실하게 만들고 그 뒤는 관찰합니다.

흔한 실수: 도달을 우리 책임으로 설계하는 것. 도달률을 목표로 잡으면 우리가 통제하지 못하는 값에 책임을 지는 셈입니다. 우리 목표는 "제공자에게 정확히 한 번 넘긴다" 이고, 도달률은 관찰하고 개선하는 값입니다.

한 겹으로 감싸 그 차이를 흡수합니다.

제공자마다 요청 형식과 인증 방식과 오류 코드가 다릅니다. 그것이 코드 전체에 퍼지면 제공자를 바꿀 때 모든 곳을 고쳐야 합니다.

우리 코드는 이 사람에게 이 알림을 보낸다만 말한다
겹 하나가 제공자 차이를 흡수한다

제공자는 실제로 바뀝니다. 문자는 가격과 도달률 때문에 옮기는 일이 흔합니다.

흔한 실수: 추상화를 최소 공통 기능으로만 만드는 것. 채널마다 고유한 것이 있습니다. 푸시의 배지 수, 메일의 첨부가 그렇습니다. 공통 부분만 남기면 그 기능을 못 쓰게 되므로, 채널 고유 항목을 담을 자리를 함께 둡니다.

제공자별 발송 속도에 상한을 두고, 거절을 받으면 줄입니다.

피크 초당 1만 을 그대로 밀면 거절당합니다.

처리율 제한 설계에서 우리가 만든 장치를 이번에는 우리가 지키는 쪽입니다. 상대가 알려 주는 재시도 시각을 따르고, 지키지 않으면 차단됩니다.

흔한 실수: 거절을 일반 오류로 보고 곧바로 재시도하는 것. 속도 제한 거절에 재시도를 붙이면 더 강하게 제한됩니다. 거절의 종류를 읽고 대응을 달리해야 합니다.

채널마다 큐와 일꾼을 나눕니다.

문자 제공자가 느려지면 그 발송이 쌓입니다. 같은 일꾼과 같은 큐를 쓰면 푸시 알림도 함께 멈춥니다.

크롤러에서 호스트별로 큐를 나눈 것과 같은 구조이고 이유도 같습니다. 한 곳의 느림이 다른 곳으로 번지지 않게 하는 것입니다.

채널마다 큐와 일꾼을 따로 둔다
한 채널이 막혀도 나머지는 흐른다

흔한 실수: 일꾼 수만 늘려 대응하려는 것. 같은 큐를 보는 일꾼을 늘리면 느린 채널의 일이 늘어난 일꾼까지 잡아먹습니다. 나누는 것과 늘리는 것은 다른 처방입니다.