요구사항과 요청 증폭

초당 약 2만입니다. 검색의 20배입니다.

초당 1,157 x 한 검색당 20타 = 초당 약 2만

자동완성은 글자마다 한 번씩 물어봅니다. 검색량이 아니라 입력량이 부하입니다.

이 숫자가 첫 결론을 강제합니다. 요청 하나에 계산을 조금이라도 두면 20배로 곱해지므로, 자동완성 요청은 읽기만 하고 아무것도 계산하지 않아야 합니다.

흔한 실수: 검색량으로 용량을 산정하는 것. 20배를 놓치면 처음부터 스무 배 작은 시스템을 설계하게 됩니다. 그리고 앞쪽 한두 글자는 제안이 무의미해서 안 물어도 되는데, 그것을 클라이언트 규칙으로 정해 두면 요청을 실제로 줄일 수 있습니다.

접두사 아래의 단어를 모아 정렬하는 것을 금지합니다.

응답이 100ms 를 넘으면 사용자의 다음 타이핑이 먼저 도착합니다. 그러면 이전 답은 화면에 뜨지도 못하고 버려집니다.

답을 만드는 데 쓸 시간이 거의 없다는 뜻입니다.

흔한 실수: 이것을 사용자 체감 목표로만 읽는 것. 이 숫자는 읽을 때 계산할 수 없다는 설계 제약입니다. 그래서 답을 미리 만들어 두는 것이 선택이 아니라 유일한 방법이 됩니다.

갱신이 하루 1회면 된다는 것과 제안이 5개면 된다는 것입니다.

실시간 갱신을 요구하면 통째로 바꾸는 방식을 쓸 수 없고, 제안을 100개 보여 달라고 하면 미리 저장하는 이득이 줄어듭니다.

흔한 실수: 요구사항에서 제약만 찾고 여유를 찾지 않는 것. 무엇이 허용되는지를 먼저 확인하면 훨씬 단순한 설계가 가능한데, 그것을 놓치면 필요 없는 실시간 구조를 만들게 됩니다.

캐시 적중률이 무너지고 초당 2만이 그대로 우리에게 옵니다.

이 시스템에서 가장 큰 자산은 답이 모든 사용자에게 같다는 것입니다. 같은 접두사에 같은 답을 주므로 한 번 만든 답을 모두에게 재사용할 수 있습니다.

개인화를 넣으면 답이 사용자마다 달라져 재사용이 사라집니다.

흔한 실수: 개인화를 품질 개선으로만 보는 것. 비용 구조를 바꾸는 결정입니다. 넣으려면 개인 신호를 소수의 집단 단위로 묶거나, 공통 답을 클라이언트에서 재정렬하는 식으로 재사용을 지켜야 합니다.