Eu argumentaria que essa é mais uma questão econômica. No entanto, essa é uma decisão que os engenheiros devem poder fazer. Por isso, estou respondendo.
Estou dividindo minha resposta em quatro partes:
- Gerenciamento de riscos
- Estratégias
- Custos
- Intuição
Gerenciamento de riscos
Portanto, algumas vezes seu cliente falha em obter uma resposta do servidor. Assumirei que isso não se deve a um erro de programação (caso contrário, a solução é corrigi-lo, então faça isso). Em vez disso, deve ser por causa de uma situação fortuita fora do seu controle ...
Mas não além do seu conhecimento. Você deve saber:
- Com que frequência isso acontece.
- Que impacto isso tem?
Por exemplo, se a falha e a nova tentativa ocorrerem apenas cerca de 2% das vezes, provavelmente não vale a pena resolvê-lo. Se isso acontece cerca de 80% das vezes, bem ... depende ...
Quanto tempo o cliente precisa esperar? E como isso se traduz em custos ... veja bem, você tem um pequeno atraso em um aplicativo regular, provavelmente não é grande coisa. Se for significativo, e você tiver um aplicativo em tempo real ou um videogame on-line, isso afastará os usuários e provavelmente você investirá em mais ou melhores servidores. Caso contrário, você provavelmente poderá colocar uma mensagem "carregando" ou "aguardando servidor". A menos que o atraso seja realmente grande (na ordem de dezenas de segundos), pode ser demais, mesmo para a aplicação regular.
Estratégias
Como eu disse acima, há mais de uma maneira de resolver esse problema. Suponho que você já tenha implementado o loop try-fail-retry. Então, vamos ver ...
- Coloque uma mensagem de carregamento. É barato, ajuda na retenção do usuário.
- Consulta em paralelo. Pode ser mais rápido, ainda pode falhar. Exigirá um servidor redundante (pode ser caro), desperdiçará tempo do servidor e tráfego de rede.
- Consulte em paralelo para estabelecer o servidor mais rápido e use-o a partir daí. Pode ser mais rápido, ainda pode falhar. Exigirá servidor redundante (pode ser caro), não desperdiçará tanto tempo do servidor e tráfego de rede.
Agora, observe que eu digo que eles ainda podem falhar. Se assumirmos que uma consulta a um servidor tem 80% de chance de falha, uma consulta paralela a dois servidores tem 64% de chance de falha. Portanto, você ainda pode precisar tentar novamente.
Uma vantagem adicional de escolher o servidor mais rápido e continuar a usá-lo é que o servidor mais rápido também tem menos chances de falhar devido a problemas de rede.
O que me lembra, se você puder descobrir por que a solicitação falhou, faça-o. Isso pode ajudá-lo a gerenciar melhor a situação, mesmo que não consiga evitar as falhas. Por exemplo, você precisa de mais velocidade de transferência no lado do servidor?
Um pouco mais:
- Implante vários servidores em todo o mundo e escolha o servidor por geolocalização.
- Faça o balanceamento de carga no lado do servidor (uma máquina dedicada atenderá a todas as solicitações e as transmitirá aos seus servidores, você poderá ter seu paralelismo ali ou uma melhor estratégia de balanceamento).
E quem disse que você precisa fazer apenas um deles? Você pode colocar uma mensagem de carregamento, consultar vários servidores espalhados pelo processo para escolher o mais rápido e usá-lo apenas a partir de então, na tentativa de falha em um loop e fazer com que cada um desses servidores seja um cluster de máquinas com balanceamento de carga . Por que não? Bem, custa ...
Custos
Existem quatro custos:
- O custo do desenvolvimento (geralmente muito barato)
- O custo da implantação (geralmente alto)
- O tempo de execução de custo (depende do tipo de aplicativo e do modelo de negócios)
- O custo do fracasso (provavelmente baixo, mas não necessariamente)
Você tem que equilibrá-los.
Por exemplo, digamos que você ganha cerca de um dólar por usuário satisfeito. Que você tenha 3000 usuários por dia. Que os pedidos falham cerca de 50% do tempo. E que 2% dos usuários saem sem pagar quando a solicitação falha. Isso significa que você está perdendo (3000 * 50% * 2%) 30 dólares por dia. Agora, digamos que o desenvolvimento do novo recurso custará 100 dólares e a implantação dos servidores custará 800 dólares - e ignorando os custos de tempo de execução - isso significa que você teria um retorno do investimento em ((100 + 800) / 30 ) 30 dias. Agora, você pode verificar seu orçamento e decidir.
Não considere esses valores representativos da realidade, eu os escolhi por conveniência matemática.
Adendos:
- Lembre-se de que também estou ignorando os detalhes. Por exemplo, você pode ter pouco custo de implantação, mas está pagando pelo tempo da CPU e precisa considerar isso.
- Alguns clientes podem apreciar se você não desperdiçar o pacote de dados em solicitações redundantes.
- Melhorar o seu produto pode ajudar a trazer propaganda natural.
- Não se esqueça dos custos de oportunidade. Você deveria estar desenvolvendo algo mais?
O fato é que, se você considerar o problema em termos de compensação de custos, poderá fazer uma estimativa do custo para as estratégias que considerar e usar essa análise para decidir.
Intuição
Intuição se promovido pela experiência. Não estou sugerindo fazer esse tipo de análise todas as vezes. Algumas pessoas fazem, e tudo bem. Estou sugerindo que você entenda isso e desenvolva uma intuição para isso.
Além disso, na engenharia, além do conhecimento que obtemos da ciência real, também aprendemos na prática e compilamos diretrizes sobre o que funciona e o que não funciona. Portanto, geralmente é aconselhável ver qual é o estado da arte ... embora, às vezes, você precise ver fora de sua área.
Nesse caso, eu examinaria os videogames online. Eles têm telas de carregamento, vários servidores, escolhem um servidor com base na latência e podem até permitir que o usuário troque de servidor. Sabemos que funciona.
Sugiro fazer isso em vez de desperdiçar o tráfego da rede e o tempo do servidor em todas as solicitações; também esteja ciente de que mesmo com o servidor redundante, pode ocorrer falha.