Escalabilidad: Implementación de Throttling y Retry Policy
Contenido del curso
Carlos Eduardo Gomez García
Vale, en este reto no sé exactamente qué tengo que hacer xD, no tengo un servicio Cloud ahora mismo(?, pero resumiendo conceptos: . Throtling: Es básicamente hacer que tu servidor devuelva un error intencionado, no es un error real, yo regresaría un error 503 (Service Unavailable Error) . BackOff: Por lo que entiendo, es el cómo manejamos los retry's, es decir, en lugar de hacer el retry un segundo después, podemos posponerlo a que se reintente en X segundos, cuando es posible que el servidor tenga menos requests . Lo que aún no me queda claro es, si regreso un error, ¿el retry debería ser automático? ¿o el retry tiene que hacerlo el usuario manualmente? 🤔
Erick Suarez Zavala
No se si aun tengas dudas :p Pero el retry tiene que ser de manera automática, en un proyecto recuerdo que teníamos un policy exponencial, si fallaba lo intentaba 2 seg. Después, si fallaba el segundo intento, 4 seg después si fallaba 8 seg. asi hasta cierto limite. Espero este ejemplo te ayude
Francisco Serrato Jiménez
Mi aporte a los conceptos serian:
Usuario anónimo
UserRecuerdo que en un proyecto realice una tarea en la que tenía que subir una gran cantidad de usuarios a Firebase (20k?), sin embargo yo tenía una tabla en csv donde me daban los usuarios y contraseñas, no hice uso del SDK que daba Firebase, decidí hacer un código en el Frontend para que subiera las cuentas con un for, recuerdo que cuando lo intente habían fallado casi todas las peticiones, y es debido a este concepto. Ahora se bien porque ocurría ese error y bueno que se le conoce en la industria como Throtling. Pienso que es una excelente forma de lidiar con este trafico poco común.
Diego Forero
Team PlatziPara Throttling sería mejor retornar un código 429 que es Too Many Requests en lugar de un error de servidor.
Flavio Andres Pareja Torres
Claro, para mi también debería responder 429 ya que no es un error del servidor sino del cliente intentando hacer demasiados llamados a la API.
Las APIs publicas como las de twilio/stripe/tmdb por lo general dicen cuanto es su throttling y de esa manera es un 4XX. en resumen, es culpa del usuario😅
Gabriel Acosta
el 429 no se refiere al cliente haciendo demasiadas peticiones? Creo que es mejor usar un error 500 puesto que al final nuestro escenario es el de muchos usuarios haciendo muchas peticiones y la incapacidad de nuestra infraestructura para hacer frente a eso. El del error 429 es el usuario intentando pegarle mucho a nuestros servidores, quizás por ejemplo, rebasando un quota limit.
Sebastian Gamba
Si nuestros servicios van a recibir mucha carga, no es viable escalar nuestras instancias basados en el computo o tiempos de respuesta ?
No entiendo como escalarían nuestros servicios si al mismo tiempo estamos rechanzando solicitudes.
Alan Mamani Huayllani
Tuve un problema similar, sin embargo, en ocaciones no se puede adquirir mas recursos dado las especificaciones del cliente dado que usamos servicios de AWS, en una lluvia de ideas se nos ocurrio una solución.
El trabajo en cuestión era de cargar una gran cantidad de datos de usuarios desde un CSV, el cual habia que convertirlo a formato JSON, para luego realizar la peticion a nuestro backend.
Nosotros decidimos usar ambas opciones para facilitar la interaccion con el usuario, viendo en tiempo real el estado de cada petición.
Carlos Fernando Aguilar González
Cristian Garcia
Para mi solución de Throttling con Firebase Realtime lo implemente de la siguiente manera
Optimizar Consultas y Estructura de Datos:
Asegúrate de que tus consultas sean eficientes y solo obtengan los datos necesarios.
Estructura tus datos de manera que minimice la cantidad de lecturas y escrituras necesarias.
Implementar Backoff Exponencial:
Si recibes un error indicando que has alcanzado el límite de solicitudes (como un código de estado 429), retrasa tus solicitudes de manera incremental.
function retryWithBackoff(retryCount) {
const delay = Math.pow(2, retryCount) * 100; // Exponential backoff
return new Promise((resolve) => setTimeout(resolve, delay));
}
async function fetchDataWithRetries(ref, retryCount = 0) {
try {
const data = await ref.get();
return data;
} catch (error) {
if (error.code === 'RESOURCE_EXHAUSTED' && retryCount < 5) {
await retryWithBackoff(retryCount);
return fetchDataWithRetries(ref, retryCount + 1);
} else {
throw error;
}
}
}
Carlos Eduardo Magallon Zepeda
Si manejan Nginx pueden leer como implementar throttling aquí
juan david jaramillo zuñiga
Exponential backoff es basicamente multiplicar el backoff time por una constante para modificar asi el tiempo en el cual el retry será realizado. Sin embargo, este approach no resuelve el problema del todo porque aun se generarian picos/valles de requests, lo que en ultimas podria sobrecargar el servidor.
Para esto, existe el approach de Jitter. Jitter es basicamente usar exponential backoff más un componente de randomness para asi repartir los subsecuentes requests de manera equitativa.
exponential_backoff = attempt_number * constant jitter = random(0, exponential_backoff)
Asi entendi los conceptos del Blog de Arquitectura de AWS
Carlos Alberto
Para este caso seria utilizar un servicio de colas como SQS de AWS?
Rodrigo Hernández
¡Hola! te podría servir para lograr tener desacoplamiento entre componentes o sistemas, y evitar por ejemplo perdida de datos (cuando por ejemplo, el sistema/componente receptor esta de baja o apagado y en lo que se restablece, podemos mantener en la cola lo que esta enviando el sistema emisor y cuando se restablezca el receptor ya los vamos liberando de la cola), también puede ayudar para temas de evitar saturación/cuellos de botella entre componentes, para mas info puedes ver la documentación oficial de AWS: https://aws.amazon.com/sqs/
Capacitacion 2
Hola. Dejo mi resolución de actividad: https://drive.google.com/drive/folders/1T_4hpEiuAvFCyhziCMMEYFSnSTPqoZA6?usp=sharing Gracias, saludos!
Christian Valenzuela
Super interesante este tema, la verdad es que es algo muy bueno ir aprendiendo de experiencias de personas como el profesor, ya que son cosas del mundo real. Este es un tema que no había escuchado en mi vida y me intereso demasiado saber como grandes empresas pueden utilizarlo
José Antonio De La Paz Fonseca
Ojalá actualicen el curso
Gonzalo Peñaranda
Eso mismo iba a comentar.
Sobre todo, reenfocarlo según los conceptos más recientes, además de cómo impactaría la IA en él.
ROMMEL DUAREZ SAENZ
si pongo un balanceador de carga al inicio que cuente las peticiones y lance la creación de VM según cantidad de peticiones? con eso no es suficiente?
J. Sebastián Botello. H.
Tengo varias preguntas...
¿De que tipo es el request?, es decir... si el request es de tipo GET, cómo lo pongo en la "cola" y al mismo tiempo envió un código de respuesta HTTP. El usuario va a recibir el error, pero la petición no respondió la información que esperaba, el usuario va a volver a enviar la petición.
En el caso de que nunca se detenga el proceso, y cada segundo entren de a dos peticiones, cómo en el ejemplo. Entonces ahí... ¿?
¿Exactamente para que tipo de peticiones el Throttling y RetryPolicies se aplicaría?
¿La escalabilidad dónde estaría...? ¿Una vez llegado a un tope de peticiones se abre una réplica o algo similar?
Brandon Rivera
Buenas, me gustaría compartir con ustedes un diagrama donde creo complementa los challenges antes mencionados. Estoy abierto a cualquier feedback para mejorar 💚.
Aquí dejo recursos por si les interesa saber más:
Juan Pablo Meza Gazabón
El status code que se podría devolver en ese caso podría ser un 429 (too many request) y no un 500 como se muestra en la clase.
Reinaldo Mendoza
No logro terminar de entender como cargar el futuro con un monton de peticiones puede ser bueno, lo entiendo como solucion a un momento pero pensando en un google que creo recibira peticiones todo el tiempo no se si existan horas valle, y si los usuarios reciben peticiones negadas buscaran otro proveedor, no lo entiendo de cara al usuario final
Alejandro Lazcano
Pasa todo el tiempo. No es novedad que incluso grandes cloud o plataformas tienen sus días de caída, no todo es perfecto. Debes planificar una política de reintentos por si falla una petición, durante un milisegundo o durante horas, luego al recomponerse todo se vuelva a conectar.
Por ejemplo: imaginate que estás esperando un paquete, el correo va informando a X plataforma que te notifique minuto a minuto la ubicación de ese paquete. El cartero pasa por un tunel y queda sin señal durante 10 minutos, pero al volver a la superficie va a mandar nuevamente la ubicación porque hay reintentos. Si no tuviera reintentos, no recibirías más actualizaciones, se cortaría todo.
Además es tremendamente difícil que un sistema escalable se mueva de proveedor, no es lo mismo que una app de hobby que quizás hoy tu subes a un hosting y mañana a otro, no es sencillo migrar una empresa.
