A煤n no tienes acceso a esta clase

Crea una cuenta y contin煤a viendo este curso

Escalabilidad: Throttling y RetryPolicies

24/25
Recursos

Aportes 9

Preguntas 2

Ordenar por:

驴Quieres ver m谩s aportes, preguntas y respuestas de la comunidad? Crea una cuenta o inicia sesi贸n.

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鈥檚, 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? 馃

Para Throttling ser铆a mejor retornar un c贸digo 429 que es Too Many Requests en lugar de un error de servidor.

Recuerdo 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.

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.

Si manejan Nginx pueden leer como implementar throttling aqu铆

Hola. Dejo mi resoluci贸n de actividad: https://drive.google.com/drive/folders/1T_4hpEiuAvFCyhziCMMEYFSnSTPqoZA6?usp=sharing
Gracias, saludos!

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

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