Carlos Eduardo Gomez García
PreguntaHay algo que todavía no entiendo, ¿qué cosas exactamente se debe especificar en el diseño de bajo nivel? porque en este ejemplo puse al frontend, el API, pero en este caso no sé como representar el API, por ejemplo, ¿debería poner a los servidores apuntando al API?, y yo aquí puse a los servidores apuntando a Laravel porque es con la tecnología que quiero trabajar, y puse a Laravel apuntando al modelo de Reviews, pero, ¿y si tengo varios modelos? ¿no sería demasiado y poco práctico poner cada modelo en este driagrama?
.
Y mi duda más grande: ¿De qué sirve tener el servicio stateless donde tengo la capacidad de aumentar servidores si así lo necesito, si al final todos acabarán llamando a la misma base de datos y será la base de datos la que tenga que procesar ese millón de solicitudes que le están llegando de cada servidor stateless? xD
- Me pasaba lo mismo que no sabia que colocar en el HLD (high level design) y el LLD (low level design), pero la clave es que el HLD que fue el primero que hicimos, míralo como el documento inicial para que un freelance te haga un presupuesto y masomenos te de un aproximado de tiempos para realizar el proyecto, sin llegar a los detalles. Mientras que el LLD ya entras a mas detalles, e incluso donde yo trabajo colocamos los mockups/wireframes/prototipos, las ips a donde se van a conectar, si hay sistemas legados en juego y detallar mas las funcionalidades, también sirve de mucho ir poniendo criterios de aceptación y limitantes como: arquitectura basada en microservicios, el sistema debe de soportar millones de requests, debe de ser asíncrono, debe de ser responsivo para todos los dispositivos, etc.
- En el caso del stateless es necesario porque así puedes utilizar funcionalidades como los ASG(auto-scaling groups / grupos de auto-escalamiento) de AWS, y esto hace que puedas ir creciendo de acuerdo a parámetros que definas (porcentaje de saturación de CPU, etc) crear o quitar maquinas virtuales (EC2) de manera automática, entonces evitas guardar estados en dichas funciones, porque como puedes tener 20 EC2 puedes llegar a volver a tener 3, y con el tema de embotellamiento a la misma base de datos, en AWS podrías definir que tipos de peticiones GET/LECTURA pueden ir a una ElastiCache por ejemplo mientras que peticiones tipo POST/INSERCION vayan directamente a la BD-master :)
Rodrigo Hernández
Hola @RetaxMaster te aclaro algunos puntos de acuerdo a mi experiencia:
