¡Listo!, ya tienes un backend montado. Está limpio y reluciente, es funcional, usa las últimas tecnologías y cumple con todos los requisitos que te pidieron. Tienes una base de datos optimizada, una API para que los usuarios obtengan la información que quieran y hasta usas una caché.
Bueno, es cierto que alguno de tus endpoints son un poquito más lentos de lo que quizás deberían pero sin demasiado peligro. Al fin y al cabo al usuario le da igual esperar 300ms que 500 ms. Incluso aunque tuviese que esperar un segundo a penas le molestaría. ¿Qué es un segundo en la vida de un humano? Nada.
Pero ¿y si resulta que un día publicas un contenido muy esperado y de golpe te encuentras con que 3.000.000 millones de usuarios lo quieren dentro del mismo rango de 5 minutos de tiempo?
Eso supondrá que un usuario ya no tendrá que esperar un segundo para obtener la información, sino que se encontrará ante un sistema saturado que le haga esperar minutos o, en el peor de los casos, nunca le de lo que pidió. Bueno sí. Cuando ese contenido ya no le interese a nadie.
Existen muchas formas de preparar a un backend ante altas concurrencias de usuarios, pero en este post, nos centraremos en
- Evitar la saturación de la base de datos
- Mejorando sus tiempos de respuesta
- Evitar accesos innecesarios
Este es ‘Daty’, una base de datos no relacional.
Su trabajo es preparar los datos, que luego sirve a los usuarios.
Pero… ¡Wow eso es mucha gente!
No estés triste Daty, lo único que necesitas es un poco de ayuda.
Aquí llega ‘John Relational’, una base de datos relacional que te facilitará tu trabajo.
John preparará los datos para que Daty sólo tenga que atender a los usuarios y pueda respirar un poco.
Pero… ¡Cuántas solicitudes! El pobre Daty no da abasto con tanto usuario.
¿Y si pedimos algo más de ayuda?
¡Hola Peter CDN! Peter es una red de distribución de contenidos.
Peter es bueno trabajando de cara al público y ayudará a Daty con los usuarios.
Ahora sí, Daty trabaja feliz.
Sé feliz. Sé como Daty.
