보이지 않는 사용 한도를 둘러싸고 설계하기

LinkedIn은 한도를 공개하지 않고, 한도는 숫자 하나도 아닙니다. 계정마다, 쓴 기간마다, 동작마다, 그리고 지난 보름이 어땠는지에 따라 달라집니다. 찾아볼 수 없으니 설계가 그것을 모른 채로도 버텨야 합니다.

429를 실패가 아니라 정보로 다루세요

429는 받을 수 있는 유일한 직접 신호입니다. 오면 물러서세요. 지수적으로, 상한을 두고요. 그리고 세는 단위는 프로세스가 아니라 계정으로 두세요. 429를 뚫고 밀어붙이는 것은 상황을 확실하게 나쁘게 만드는 유일한 행동입니다. 기다림이 길어집니다.

큐는 작업별이 아니라 계정별로

전역 작업자 풀은 부하를 인프라 전체에 퍼뜨리는 한편, 마침 가장 바쁜 계정에 몰아줍니다. 연결된 계정마다 각자의 속도 조절을 가진 큐를 하나씩 두는 것은 코드가 더 많지만, 버티는 유일한 모양입니다. 계정별 과금 모형도 읽기 쉬워집니다. 큐를 쌓는 단위가 곧 값을 치르는 단위이니까요.

일을 중간에 끊을 수 있게 만드세요

중간에 멈출 수 없는 것은 결국 중간에 죽습니다. 진행을 저장하고, 단계마다 멱등하게 하고, 이어서 하게 두세요. 이는 웹훅 재시도를 무해하게 만드는 바로 그 성질이고, 우연이 아닙니다. 같은 문제이기 때문입니다.

LinkedIn에 닿은 것을 재세요

받아들여진 요청과 눈에 보이는 결과를 따로 세세요. 둘이 벌어질 때, 달리 볼 수 없던 한도에 대해 무언가를 배운 것입니다. 게다가 고객이 말해 주기 전에 배웠습니다.

자주 묻는 질문