서버에 요청 100개가 한꺼번에 들어오고, 요청마다 작업이 하나씩 있다고 해 봐요. 워커는 4개, 채널에는 작업 8개가 들어갈 자리를 둬요. 요청이 몰리는 동안 끝나는 작업은 없다고 가정해요. 작업 4개는 실행 중이고 8개는 큐에 들어갈 수 있어요. 각 요청이 작업을 보내는 고루틴을 이미 띄웠다면, 나머지 고루틴 88개는 전송을 기다릴 수 있어요. 큐에는 상한이 있어요. 기다리는 고루틴 수에는 별도의 상한이 필요해요.
버퍼가 있는 채널은 그 안에 저장되는 값의 수를 제한해요. 전송하다 막히는 고루틴이 몇 개까지 도달할지는 정하지 않아요. 전송을 새 고루틴으로 옮기면 기다리는 위치만 바뀌어요. 버퍼가 없는 채널은 값을 주고받는 시점에 송신자와 수신자를 동기화하지만, 도착하는 송신자 수까지 제한하지는 않아요.
이 설계에서는 요청 진입점을 작업 수락의 책임자로 정하겠어요. 추가 작업을 띄우기 전에 자리를 확보하거나, 자리가 없으면 포화 상태를 알리는 결과를 반환해야 해요. 수락할 때까지 기다리게 한다면 그 대기에도 인원 제한과 기한이 필요해요. 그렇지 않으면 큐가 앞단으로 옮겨 갔을 뿐이에요.
호출자가 떠났을 때 취소 신호를 보내는 책임은 요청 핸들러에 두겠어요. 큐의 작업을 시작하기 전과 작업을 멈추기 적절한 지점에서 신호를 확인하는 책임은 워커에 둬요. 취소 신호만으로는 자리가 언제 반환되는지 알 수 없어요. 수락 책임자에게는 작업이 제한 대상 자원을 실제로 점유하지 않게 될 때까지 그 작업을 계속 세는 규칙이 필요해요.
처음부터 작은 작업 12개로 제한된 배치라면 고루틴 12개를 바로 띄우는 것도 타당해요. 이때 워커 풀은 상한을 더 낮추지 못하면서 조율만 늘릴 수 있어요. 요청이 계속 들어올 때는 어느 구성 요소가 그 상한을 책임지나요?