Escalabilidad: Throttling y RetryPolicies

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? 🤔

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