Concorrência no envio de OTP por SMS: estados, bloqueios e reenvios
Conheça os limites da evidência disponível sobre solicitações simultâneas de OTP e os controles de frequência descritos para envios por SMS.
O problema: várias solicitações para uma única verificação
Um toque repetido, duas abas abertas ou solicitações que chegam quase ao mesmo tempo podem iniciar mais de um fluxo de OTP. Também pode acontecer de dois workers processarem solicitações equivalentes simultaneamente. O que ocorrerá em cada caso depende da arquitetura da aplicação e da API ou conexão de envio utilizada; a evidência disponível não permite estabelecer uma estratégia geral para coordenar esses processos.
A documentação de ClickSend descreve controles de frequência, como estabelecer um máximo de OTP por minuto ou bloquear temporariamente usuários. O trecho disponível não confirma detalhes de implementação nem garante que esses controles impeçam processamentos simultâneos.
- Verifique na documentação aplicável quais controles de frequência estão disponíveis e o que fazem.
- Não presuma que um limite de solicitações também evita processamentos duplicados.
- Não interprete a ausência de uma resposta imediata como prova de que o envio não foi iniciado.
Separe a verificação, o código e a tentativa de envio
Ao avaliar o fluxo, diferencie a solicitação de autenticação, o OTP associado e a tentativa de envio da mensagem. Essa distinção ajuda a identificar quais informações a aplicação registra, mas a evidência disponível não especifica um modelo de dados ou uma política universal.
Antes de definir o comportamento, determine o que significa «a mesma operação» no seu produto. O tratamento de uma solicitação repetida depende das sessões, verificações e regras definidas pela aplicação.
- Identifique como a aplicação relaciona uma solicitação à verificação correspondente.
- Consulte a documentação técnica para saber quais identificadores e resultados estão disponíveis.
- Não assuma que o número de telefone, isoladamente, define solicitações equivalentes.
Defina uma chave de operação com escopo claro
Uma chave de operação ou mecanismo equivalente pode fazer parte de uma solução de deduplicação, mas as fontes disponíveis não verificam uma estratégia concreta nem garantem seu comportamento. A escolha de critérios e escopo depende da aplicação e deve ser validada com a arquitetura utilizada.
Mantenha separada a questão da deduplicação das regras de frequência ou bloqueio temporário. A documentação de ClickSend menciona controles de frequência, mas o trecho fornecido não descreve uma chave de operação nem explica como ela interagiria com esses controles.
- Documente como a aplicação identifica solicitações que considera equivalentes.
- Valide a estratégia com a arquitetura e a documentação técnica aplicáveis.
- Evite incluir dados confidenciais desnecessários em identificadores ou registros operacionais.
Use estados explícitos e coordenação validada
Estados como «em processamento», «aceito» ou «resultado incerto» podem ser escolhas de desenho da aplicação, mas a evidência disponível não verifica uma máquina de estados recomendada. Defina os estados com base nas respostas efetivamente documentadas pela API ou conexão utilizada.
A documentação fornecida também não confirma um mecanismo de reivindicação atômica nem que um bloqueio em memória coordene várias instâncias. Se a aplicação precisar dessa coordenação, valide a solução com a arquitetura e os mecanismos de armazenamento compartilhado que utiliza.
- Baseie os estados nos resultados que a aplicação e o provedor realmente comunicam.
- Verifique na documentação e na arquitetura próprias como solicitações simultâneas são coordenadas.
- Não transforme uma tarefa interna criada em uma afirmação de que o provedor aceitou o envio.
Defina a política de reutilização e substituição do código
A evidência disponível não permite recomendar quando reutilizar um OTP vigente, gerar outro ou invalidar códigos anteriores. Essas regras dependem das decisões de segurança e funcionamento da aplicação e precisam ser definidas e verificadas no contexto próprio.
Documente como geração, expiração, invalidação e validação se relacionam. Não apresente uma regra como universal sem suporte da política adotada e da implementação correspondente.
- Defina o que a aplicação considera uma repetição e o que considera uma nova verificação.
- Documente como o código anterior será tratado se um novo for gerado.
- Alinhe a mensagem exibida ao usuário ao estado que a aplicação consegue confirmar.
Trate timeouts conforme a documentação disponível
A evidência fornecida não descreve o que acontece com uma solicitação de envio após um timeout nem permite recomendar uma regra concreta de reenvio. O resultado depende do comportamento documentado da API ou conexão utilizada.
Antes de definir novas tentativas, consulte a documentação técnica para saber quais resultados, identificadores ou consultas de status estão disponíveis. Não presuma que um timeout prova que o provedor não recebeu a solicitação.
- Diferencie um timeout observado pela aplicação de uma rejeição comunicada pelo provedor.
- Verifique na documentação aplicável o comportamento de timeouts e solicitações repetidas.
- Não afirme que o usuário receberá um único SMS quando isso não estiver confirmado.
Deduplicação interna e idempotência do provedor
A evidência disponível não confirma se uma API ou conexão de envio oferece idempotência nem como reconhece solicitações repetidas. Não trate esse mecanismo como uma capacidade presente sem consultar a documentação técnica aplicável.
Também não é possível concluir que HTTP ou SMPP, por si só, ofereçam deduplicação de negócio para um OTP. Verifique as especificações e a documentação da API ou conexão utilizada antes de depender de qualquer comportamento desse tipo.
- Consulte a documentação técnica para confirmar se há um mecanismo de idempotência e qual é seu escopo.
- Não presuma que uma solicitação repetida será reconhecida ou deduplicada.
- Se o comportamento não estiver documentado, não apresente uma garantia de ausência de duplicações.
Preserve a rastreabilidade e os limites de interpretação
Registros operacionais podem ajudar a reconstruir o que a aplicação observou em solicitações simultâneas. Defina quais dados registrar, com que finalidade e por quanto tempo, considerando as obrigações aplicáveis e as informações realmente disponíveis.
A evidência fornecida não permite afirmar que um status de entrega prove que o SMS chegou ao terminal. Consulte a documentação do provedor para entender o alcance do status recebido e diferencie esse dado da conclusão da autenticação.
- Diferencie o resultado observado pela aplicação do status informado pelo provedor.
- Não exponha o código OTP em registros operacionais.
- Verifique na documentação do provedor o significado dos estados comunicados.
Perguntas frequentes
Uma chave de operação garante que apenas um SMS será enviado?
A evidência disponível não permite afirmar isso. O comportamento depende da implementação da aplicação e da API ou conexão utilizada; confirme-o na documentação técnica aplicável.
Devo gerar um novo OTP sempre que o usuário tocar em «reenviar»?
As fontes fornecidas não estabelecem uma regra universal. Defina a política da aplicação para solicitações repetidas, códigos vigentes e substituição, e verifique se a implementação a aplica de forma consistente.
O que fazer quando o envio termina em timeout?
A evidência disponível não especifica uma política de reenvio. Consulte a documentação da API ou conexão para entender o comportamento do timeout e não presuma que ele prova que a solicitação não foi recebida.
Um status de entrega confirma que o SMS chegou ao telefone?
A evidência fornecida não permite concluir isso. Consulte a documentação do provedor para verificar o que o status representa e não o equipare ao recebimento no terminal sem confirmação específica.