Yo diría que esto es más una cuestión económica. Sin embargo, ese es un juicio que los ingenieros deberían poder hacer. Por lo tanto, estoy respondiendo.
Estoy dividiendo mi respuesta en cuatro partes:
- Gestión de riesgos
- Estrategias
- Costos
- Intuición
Gestión de riesgos
Entonces, a veces su cliente no puede obtener una respuesta del servidor. Asumiré que esto no se debe a un error programático (de lo contrario, la solución es solucionarlo, así que hazlo). En cambio, debe ser debido a una situación fortuita más allá de su control ...
Pero no más allá de tu conocimiento. Debes saber:
- ¿Con qué frecuencia sucede?
- ¿Qué impacto tiene?
Por ejemplo, si falla y vuelve a intentarlo solo aproximadamente el 2% del tiempo, probablemente no valga la pena abordarlo. Si ocurre alrededor del 80% del tiempo, bueno ... depende ...
¿Cuánto tiempo tiene que esperar el cliente? ¿Y cómo se traduce eso en costos? Verá, tiene una pequeña demora en una aplicación normal, probablemente no sea gran cosa. Si es significativo, y tiene una aplicación en tiempo real o un videojuego en línea, esto alejará a los usuarios y probablemente sea mejor que invierta en más o mejores servidores. De lo contrario, probablemente pueda poner un mensaje de "cargando" o "esperando al servidor". A menos que la demora sea realmente grande (del orden de decenas de segundos), puede ser demasiado incluso para la aplicación normal.
Estrategias
Como dije anteriormente, hay más de una forma de solucionar este problema. Asumiré que ya tiene implementado el bucle try-fail-retry. Entonces, veamos ...
- Pon un mensaje de carga. Es barato, ayuda a la retención del usuario.
- Consulta en paralelo. Puede ser más rápido, aún puede fallar. Requerirá un servidor redundante (puede ser costoso), desperdiciará el tiempo del servidor y el tráfico de red.
- Consulte en paralelo para establecer el servidor más rápido y usarlo a partir de ahí. Puede ser más rápido, aún puede fallar. Requerirá un servidor redundante (puede ser costoso), no desperdiciará tanto tiempo de servidor y tráfico de red.
Ahora, note que digo que aún pueden fallar. Si suponemos que una consulta a un servidor tiene un 80% de posibilidades de falla, entonces una consulta paralela a dos servidores tiene un 64% de posibilidades de falla. Por lo tanto, es posible que deba volver a intentarlo.
Una ventaja adicional de elegir el servidor más rápido y seguir usándolo es que el servidor más rápido también tiene menos probabilidades de fallar debido a problemas de red.
Lo que me recuerda, si puede descubrir por qué falla la solicitud, hágalo. Puede ayudarlo a manejar mejor la situación, incluso si no puede evitar las fallas. Por ejemplo, ¿necesita más velocidad de transferencia en el lado del servidor?
Algo mas:
- Implemente varios servidores en todo el mundo y elija el servidor por geolocalización.
- Haga el equilibrio de carga en el lado del servidor (una máquina dedicada tomará todas las solicitudes y las reenviará a sus servidores, puede tener su paralelismo allí o una mejor estrategia de equilibrio).
¿Y quién dijo que tienes que hacer solo uno de estos? Puede poner un mensaje de carga, consultar varios servidores que se extienden por todo el mundo para elegir el más rápido y solo usarlo a partir de ahí, en caso de error, vuelva a intentarlo en un bucle y haga que cada uno de esos servidores sea un grupo de máquinas con equilibrio de carga . Por qué no? Bueno, cuesta ...
Costos
Hay cuatro costos:
- El costo de desarrollo (generalmente muy barato)
- El costo de implementación (generalmente alto)
- El tiempo de ejecución de costos (depende del tipo de aplicación y el modelo de negocio)
- El costo de la falla (probablemente bajo, pero no necesariamente)
Tienes que equilibrarlos.
Por ejemplo, digamos que gana aproximadamente un dólar por usuario satisfecho. Que tienes 3000 usuarios por día. Que las solicitudes fallan aproximadamente el 50% del tiempo. Y ese 2% de los usuarios se van sin pagar cuando la solicitud falla. Esto significa que está perdiendo (3000 * 50% * 2%) 30 dólares por día. Ahora, digamos que desarrollar la nueva característica le costará 100 dólares y la implementación de los servidores le costará 800 dólares, e ignorando los costos de tiempo de ejecución, esto significa que tendría un retorno de la inversión en ((100 + 800) / 30 ) 30 dias. Ahora, puede consultar su presupuesto y decidir.
No considere estos valores representativos de la realidad, los elegí por conveniencia matemática.
Addendums:
- Recuerda que también estoy ignorando los detalles. Por ejemplo, puede tener un bajo costo de implementación, pero está pagando por el tiempo de CPU y debe tenerlo en cuenta.
- Algunos clientes pueden apreciar si no desperdicia su paquete de datos en solicitudes redundantes.
- Mejorar su producto puede ayudar a traer publicidad natural.
- No olvide los costos de oportunidad. ¿Deberías estar desarrollando algo más?
La cuestión es que si considera el problema en términos de equilibrar costos, puede hacer una estimación del costo de las estrategias que considera y utilizar este análisis para decidir.
Intuición
Intuición si se fomenta por experiencia. No sugiero hacer este tipo de análisis cada vez. Algunas personas lo hacen, y eso está bien. Le sugiero que comprenda algo de esto y desarrolle una intuición.
Además, en ingeniería, además del conocimiento que obtenemos de la ciencia real, también aprendemos en la práctica y compilamos pautas de lo que funciona y lo que no. Por lo tanto, a menudo es aconsejable ver cuál es el estado del arte ... aunque, a veces, necesita ver fuera de su área.
En este caso, miraría los videojuegos en línea. Tienen pantallas de carga, tienen múltiples servidores, elegirán un servidor en función de la latencia e incluso pueden permitir que el usuario cambie de servidor. Sabemos que funciona.
Sugeriría hacer eso en lugar de perder el tráfico de red y el tiempo del servidor en cada solicitud, también tenga en cuenta que incluso con un servidor redundante, puede ocurrir una falla.