최근에 바뀐 것만 가져오려 했는데 상대 API에 그런 정렬이 없었다. 식별자 역순만 되고 수정 시각으로는 정렬할 수 없어서 전부 받아서 우리가 걸러야 했다.
Table of contents
Open Table of contents
12건을 위한 4만 건
전체 4만여 건을 받아 최근 바뀐 12건을 고르는 구조였다. 받는 양과 쓰는 양의 차이가 세 자릿수여서 이 상태로는 자주 돌릴 수 없었다.
정렬이 없다는 것에서 멈추지 않고 다른 이름으로 같은 일을 하는 것이 있는지를 문서에서 찾았다. 수정 시각 필터가 있는지와 웹훅이 있는지와 변경 목록 API가 있는지 셋을 봤다.
다른 이름으로 있던 것
변경 목록 API가 있었고 목차에 안 보이는 자리에 들어 있었다. 시각을 주면 그 뒤로 바뀐 것만 돌려주는 형태였고 실제로 12건만 받았다.
정렬이라는 이름으로 없다고 판단한 기능이 다른 이름으로 존재했다. 문서 목차만 훑고 없다고 결론 내면 이런 것을 놓친다.
변경 목록이 없는 연동
변경 목록 API가 없는 다른 연동도 있어서 그쪽은 전부 받아야 했다. 대신 받는 양을 줄이는 방법을 찾았다.
필드 선택이 되는 곳은 식별자와 수정 시각만 받아서 크기를 10분의 1로 줄이고, 그것으로 거른 뒤 바뀐 것의 상세만 다시 받았다. 필드 선택도 안 되는 곳은 받은 것의 해시를 저장해 두고 비교해서 받는 양은 그대로여도 처리하는 양을 줄였다.
받는 비용에 따라 주기도 달리했다. 변경 목록이 있으면 5분마다 돌리고 필드 선택만 되면 한 시간마다 하며 전부 받아야 하는 곳은 하루 한 번으로 뒀다. 그만큼 반영이 늦다는 것을 문서에 적었다.
요청과 기록
상대에게 수정 시각 기준 정렬이나 필터가 있으면 양쪽 부하가 준다고 요청해 뒀다. 반년 뒤에 생겼고 요청해 두지 않았으면 안 생겼을 수도 있다.
그동안의 방법도 함께 적었다. 지금 무엇을 하고 있는지와 왜 그렇게 하는지와 무엇이 생기면 어떻게 바꿀지를 적어 두니 반년 뒤 API가 생겼을 때 그 메모를 보고 바로 바꿨다. 언제 바꿀지를 안 적으면 조건이 충족돼도 아무도 안 바꾼다.
빠른 방법과 확실한 방법
변경 목록 API가 생겨서 그것을 쓰기 시작했는데 빠진 것이 있었다. 목록에는 12건인데 실제 변경은 14건이었고 상대 쪽에서 목록에 안 넣는 종류가 있었다.
변경 목록만 믿으면 놓치므로 5분마다 변경 목록으로 반영하되 하루 한 번 전체 대조를 같이 돌렸다. 대조에서 빠진 것이 나오면 반영하고 로그에 남겼는데 며칠 세어 보니 하루 한두 건이었고 상대에게 알려 그쪽에서 고쳤다. 빠른 방법과 확실한 방법을 같이 두고 하나만 믿지 않은 것이 그 누락을 드러냈다.
정리
- 상대가 주는 정렬 기준으로만 뽑을 수 있다
- 없는 것 같아도 다른 이름으로 있을 수 있다
- 없으면 받는 양을 줄이고 필요한 필드만 받는다
- 그것도 안 되면 해시로 비교해 처리량을 줄인다
- 받는 비용에 따라 주기를 달리하고 반영이 늦는 것을 적는다
- 상대에게 요청해 두지 않으면 안 생긴다
- 왜 이렇게 하는지와 언제 바꿀지를 적는다
- 빠른 방법과 확실한 방법을 같이 두고 하나만 믿지 않는다