요청 제한을 검증할 때 먼저 바꿔야 할 것은 요청 수가 아니라 목적지다. 여러 인스턴스로 실행되는 API 서비스에서 같은 사용자의 요청을 서로 다른 복제본으로 보낸다. 어느 복제본에 도착하든 하나의 한도가 적용돼야 한다. 이 조건을 빼면 제한 장치의 가장 중요한 실패가 테스트 밖에 남는다.
프로세스 로컬 카운터는 한 인스턴스 안에서 정확할 수 있다. 제한값에 도달하면 예상한 응답도 낸다. 하지만 로드 밸런서가 다음 요청을 다른 인스턴스로 보내면 그곳의 카운터는 처음부터 시작한다. 각 장부의 계산은 맞아도 서비스 전체의 정책은 새는 구조다.
그래서 배포 구조가 달라지면 요청 제한의 검증 기준도 달라져야 한다. 여러 인스턴스나 컨테이너, 서버리스 실행 환경에서는 프로세스 안의 카운터를 전체 서비스의 제한 상태로 간주할 수 없다. 제한 상태는 실제 배포 토폴로지와 맞아야 하며, 서로 다른 인스턴스를 거치는 요청으로 그 사실을 확인해야 한다.
공유 상태를 사용했다는 설정만 확인하는 것으로도 부족하다. 운영 경로에서 두 요청이 다른 복제본을 지나도 같은 제한에 묶이는지가 합격 조건이다. 단일 인스턴스 테스트가 통과했다는 사실은 로컬 구현만 증명한다. 사용자가 마주하는 한도까지 증명하지는 않는다.
서버를 늘렸다는 이유로 허용량까지 늘어나서는 안 된다. 확장 후에도 같은 정책을 지키는지 확인하지 않았다면 요청 제한은 아직 배포된 기능이 아니다.