Fila de concorrência da API Carrier Lookup para slots de conta compartilhada

Uma fila de concorrência da API Carrier Lookup deve coordenar todos os trabalhadores usando uma única conta, em vez de deixar que cada processo tente adivinhar sua própria capacidade disponível.

Uma fila de concorrência da API Carrier Lookup deve coordenar todos os trabalhadores usando uma única conta, em vez de deixar que cada processo tente adivinhar sua própria capacidade disponível. O CarrierLookup documenta slots de tempo real simultâneos compartilhados e um portão de conta separado para solicitações múltiplas. Encaminhe solicitações únicas e múltiplas síncronas através de um controlador de nível de conta, preserve a ordem de entrada para cada solicitação múltipla e libere um slot apenas após o término dessa solicitação. Esses controles gerenciam o trabalho simultâneo; eles não representam uma cota por minuto nem uma promessa sobre o tempo de resposta.

Modele a conta, não um trabalhador de aplicativo individual

A Consulta da operadora original retorna o contexto de alocação original do número: a operadora originalmente alocada, a operadora subjacente, o tipo de número e a geografia da alocação. Ela não informa a operadora atual após a portabilidade nem se um número pode receber uma chamada ou mensagem. "Tempo real" aqui refere-se ao fluxo de trabalho de solicitação e resposta, não a uma sonda de rede ao vivo. A API de Consulta da operadora original é a página de produto relevante, e a documentação da API deve permanecer a fonte para detalhes atuais de integração.

Quando vários serviços compartilham uma conta de API, um semáforo por processo é insuficiente. Dois trabalhadores da Web, uma importação em segundo plano e uma ferramenta de análise podem acreditar, cada um, que a conta possui slots livres. As regras públicas documentadas descrevem cinco slots de tempo real simultâneos compartilhados e uma solicitação múltipla por conta. Um controlador do lado do cliente deve, portanto, usar um coordenador único de nível de conta ou outro mecanismo que forneça a todos os trabalhadores participantes uma visão consistente das chamadas pendentes. A tecnologia exata de armazenamento ou fila é uma escolha de implementação do cliente.

A fila deve conter um envelope de solicitação com o(s) identificador(es) E.164 enviado(s), modo de solicitação, referência de trabalho do aplicativo e o horário em que a equipe o enfileirou. Esses são campos propostos de propriedade do cliente, não uma afirmação sobre o esquema de resposta do CarrierLookup. Evite registrar números completos ou credenciais, a menos que a política da organização exija e os proteja.

Dê portões separados para chamadas únicas e múltiplas

Uma consulta única aceita um número E.164. A múltipla síncrona aceita de 1 a 100 números E.164 e retorna um resultado ordenado em uma única resposta. Ambas são verificações em tempo real, mas a rota múltipla também possui uma restrição de uma solicitação por vez em toda a conta. Projete dois portões: um contador de capacidade compartilhada para todas as solicitações em tempo real em andamento e um portão exclusivo para solicitações múltiplas. Uma chamada múltipla deve adquirir a capacidade necessária sob as regras documentadas da conta e o portão múltiplo exclusivo; a implementação deve liberar ambos juntos após uma resposta concluída ou falha terminal.

Não trate uma solicitação múltipla como uma tarefa de arquivo em lote assíncrona. O produto separado de consulta de operadora global aceita arquivos TXT ou CSV, prepara identificadores e, posteriormente, produz um CSV. Ele pertence a um fluxo de trabalho diferente. A página como o CarrierLookup funciona ajuda os leitores a distinguir esses modos. Se o aplicativo tiver um trabalho de arquivo grande, escolha deliberadamente o produto em lote documentado em vez de enviar um arquivo para a fila síncrona.

O coordenador também precisa de imparcialidade. Um fluxo constante de solicitações únicas não deve esgotar uma solicitação múltipla já enfileirada, enquanto uma grande importação não deve bloquear indefinidamente pequenas verificações interativas. Uma regra de agendamento de propriedade do cliente pode reservar turnos por ordem de chegada ou usar uma política de prioridade limitada. Esta é uma recomendação de fluxo de trabalho, não uma garantia de agendamento do provedor.

Trate o tempo limite e a falha do trabalhador como eventos terminais da fila

Uma solicitação única e uma solicitação múltipla possuem limites de tempo limite documentados na API pública. Use a documentação atual da API para os valores exatos e o contrato de resposta, em vez de assumir um tempo normal de conclusão. Um tempo limite do lado do cliente pode deixar incerteza sobre se o servidor concluiu a chamada, portanto, um controlador deve registrar essa incerteza separadamente de um resultado de operadora concluído. Para a múltipla síncrona, o produto documenta que um tempo limite múltiplo falha em toda a solicitação sem resultados parciais e retorna o valor total. Não crie sucessos em nível de linha a partir de uma resposta incompleta.

Cada concessão de fila precisa de um caminho de liberação, mesmo se um trabalhador do aplicativo travar. O controlador do cliente pode marcar o trabalho como incerto, liberar a capacidade local assim que o trabalhador for considerado ausente e encaminhar a solicitação para uma revisão ou política de nova tentativa cuidadosamente controlada. Não inunde automaticamente o serviço com novas tentativas após um incidente de rede. Se uma nova tentativa for escolhida, preserve a referência original do trabalho do aplicativo e distinga a observação posterior da tentativa incerta anterior.

Uma consulta concluída pode conter campos de operadora vazios e permanecer um resultado concluído e cobrável. Isso não é um tempo limite e não deve consumir uma nova tentativa apenas para forçar uma operadora não vazia. Por outro lado, um formato de entrada rejeitado não é um resultado de "sem operadora". A fila registra o estado da solicitação; ela não reinterpreta o significado da consulta.

Monitore a fila sem inventar um limite de taxa

Métricas úteis do lado do cliente incluem solicitações únicas em andamento, se uma solicitação múltipla está ativa, idade na fila por classe de trabalho, respostas concluídas, rejeições de formato, tempos limite e resultados de transporte incertos. Elas mostram se o aplicativo está respeitando a concorrência e se os usuários estão esperando por um trabalhador controlado pelo cliente. Elas não implicam um limite fixo de solicitações por minuto ou diário, o que os fatos públicos não declaram.

Antes do lançamento, teste dois trabalhadores da Web enviando solicitações ao mesmo tempo, uma solicitação múltipla enfileirada enquanto solicitações únicas estão ativas, a saída de um trabalhador antes da resposta e um tempo limite. Confirme se não há mais de uma solicitação múltipla ativa para a conta e se todos os portões locais adquiridos são eventualmente liberados. Verifique se o resultado corresponde ao número canônico enviado e se as linhas múltiplas ordenadas são reconciliadas antes de atualizar os registros de contato.

Uma nota operacional final deve explicar que a operadora retornada descreve a alocação original. Uma fila rápida ainda precisa de um rótulo preciso para a alocação da operadora original. Armazene-o com uma fonte e horário de verificação, mantenha a região e a cidade de alocação separadas da localização de uma pessoa e use outras evidências para questões de contatabilidade ou identidade.

Perguntas frequentes

Como as equipes devem coordenar vários trabalhadores usando uma conta CarrierLookup?

Use um controlador de nível de conta que todos os trabalhadores compartilhem, com um portão de capacidade de tempo real compartilhado e um portão exclusivo para solicitações múltiplas síncronas.

A regra de concorrência documentada cria uma cota por minuto?

Não. Ela limita o trabalho simultâneo em andamento e não declara um número fixo de solicitações por minuto.

Uma solicitação múltipla com tempo limite pode ser parcialmente aceita?

O tempo limite múltiplo documentado falha em toda a solicitação sem resultados parciais. Mantenha-a como uma falha em nível de solicitação e não invente linhas bem-sucedidas.

Campos de operadora vazios devem acionar uma nova tentativa automática?

Não por si só. Uma consulta concluída com campos de alocação vazios permanece um resultado concluído; a equipe deve preservar esse resultado com precisão.

Saiba mais

Escolha as informações do produto que se ajustam à próxima etapa do seu fluxo de trabalho.

• Ver a documentação do produto →
• Falar com a equipe →