La arquitectura del sistema es uno de los elementos fundamentales al desarrollar un sistema distribuido. Consiste en plasmar los componentes del sistema a partir de los requerimientos de negocio, detallando cómo se conectan entre sí los distintos servicios y bases de datos. Esto se visualiza a través de bocetos o diagramas que luego se pueden formalizar utilizando herramientas de diseño de diagramas. Esta representación gráfica nos permite tener una vista clara y organizada de cómo opera y se interconecta el sistema.
¿Qué es una entrevista de diseño de sistemas?
Al aplicar a puestos de desarrollo de software en grandes empresas, es común enfrentarse a una entrevista de diseño de sistemas. Este tipo de entrevistas evalúa la capacidad de los candidatos para diseñar la arquitectura de un sistema basado en un problema específico. Por ejemplo, uno podría ser solicitado para diseñar un sistema de reviews de cámaras, donde los editores suben reviews y otros usuarios los leen.
Preguntas clave en una entrevista de diseño
¿Cuántos usuarios van a leer los reviews?: Esto determina el tráfico esperado y ayuda a planificar el escalamiento del sistema.
¿Cuántos editores habrá?: Un menor número de editores respecto a lectores puede significar que las necesidades de escalamiento son diferentes para el servicio de escritura.
¿Cuál es el tiempo de respuesta esperado?: Definir los tiempos de respuesta para lectura y escritura ayuda a establecer expectativas sobre la latencia que el sistema debe manejar.
Planificación del sistema
Al diseñar un sistema, es crucial visualizar la interacción entre usuarios, servicios y bases de datos. Por ejemplo:
Interacción del usuario: Los usuarios realizan peticiones HTTP que interactúan con el sistema a través de plataformas móviles o web.
Escalabilidad global: Configurar el sistema para que sea replicable en diferentes regiones globales, garantizando que el sistema soporte a millones de usuarios.
Servicios y bases de datos
Servicio de escritura: Implementado como una función serverless que procesa subidas de reviews.
// Ejemplo de servicio de escritura con una función serverless
AWS Lambda o Azure Function reciben la petición y guardan en una base de datos noSQL.
Servicio de lectura: Opera mediante un clúster de máquinas virtuales, asegurando que las peticiones de lectura sean eficientes.
// Ejemplo de servicio de lectura
Conecta con una base de datos relacional, potencialmente optimizada con cachés para aumentar la velocidad.
Procesamiento de datos: Un servicio adicional podría procesar la información desde una base de datos noSQL hacia una base de datos relacional según sea necesario.
Herramientas para representar la arquitectura
Es vital traspasar tu boceto de arquitectura a un diseño formal mediante herramientas como Diagrams.net. Esta herramienta facilita la creación de diagramas UML que reflejan la estructura y relación de los componentes del sistema. Al documentar y visualizar la arquitectura, se facilita el feedback y se promueve la mejora continua del diseño.
¿Cómo asegurarse de que la arquitectura soporta el crecimiento?
Al diseñar la arquitectura, es crucial anticipar cómo escalará el sistema con el crecimiento de usuarios y casos de uso adicionales. A medida que el sistema evoluciona, es vital revisar continuamente los componentes y asegurarse de que el diseño sigue siendo eficiente y eficaz para cumplir con los objetivos de negocio.
Aquí se empieza a ver lo que es un sistema distribuido, podemos ver como todo es agnóstico a todo y se unen por comunicación. Cuando hablamos de lectura (POST) recordamos que solo son 10 usuarios que van a estar escribiendo, es por eso que no hacemos tanto énfasis en ello, incluso una base de datos NoSQL puede bastar, ya que realmente se va a estar leyendo muy poco.
.
En cambio para la lectura, son mils de usuarios, así que ahí necesitamos tener poder de procesamiento, además de que tenemos que entregar respuesta de manera inmediata. Las bases de datos SQL suelen ser mejor para lectura, ya que con ellas podemos realizar querys complejas y obtener el resultado que deseamos (cosa que no podríamos con una NoSQL, a no ser que suframos)
.
De hecho, incluso podríamos tener una tercera base de datos que almacene esos datos que no se está usando y esa base de datos puede ser usada para Machine Learning y Business Intelligence.
.
Recomiendo el curso de Fundamentos de Bases de Datos
para profundizar en para qué es bueno cierto tipo de bases de datos.
En este caso, no entiendo que justifica el uso de una base de datos relaciónale SQL, ya que con la base de datos NoSQL ya podemos almacenar, ordenar e indexar las reviews de la forma que más necesitemos. Quiero decir, las queries según los casos de uso no son complejas, xq usar SQL??
Desde este punto de vista donde usamos queries no tan complejas, una base de datos NOSQL podría bastar, pero pensamos en escalabilidad, recuerda que el sistema debe poder ser escalable así que es bueno pensar a futuro, y para lectura una base de datos relacional es una maravilla
Otra herramienta muy popular para diagramación es:
Lucidchart
Este curso debería estar en las rutas de desarrollo backend que hay en Platzi, lo encontré por casualidad
Debería ser uno de los primeros, así se va con conocimientos de como ir creando/modelando el proyecto.
Excelente clase!
Lo resumo así:
Entender el problema resolver.
Realizar las preguntar pertinentes.
Evaluar los escenarios o casos de uso del problema.
Bosquejar soluciones posibles.
Pedir feedback.
Buen resumen sería ¿Todo?
Team, me ayudan a entender como o en que momento se dispara el servicio 3 ?, me imagino algo como un job que dispare ese servicio o que el servicio de escritura dispare un webhooks asi desencadenar el servicio 3, tambien esta por eventos, pero quisiera saber si estoy por el buen camino de comprension
A mi entender si sería una tarea programada que se ejecuta una vez al día, seguramente con una expresión cron para dispararse automáticamente
Por ejemplo en AWS se programar la ejecución de una función Lambda utilizando los eventos de CloudWatch Tutorial: Schedule AWS Lambda Functions Using CloudWatch Events
Aquí mi diagrama, que mejorarían / cambiarían?
Ya se pueden observar desde el diseño las ventajas que ofrece un sistema distribuido, ya que los servicios están incluso en diferentes regiones el hecho de que nuestro servicio para subir reviews se caiga no afecta en los más mínimo a nuestros usuarios que leen las reviews.
Tengo una duda y es con el servicio 3, en que momento es optimo pasar lo que se inserto en la db no relacional, a la db relacional,de igual forma porque es mejor dejarlo con esa estructura que indica en el video y simplemente dejar una db de escritura y lectura y hacer un espejo en otro servidor para que cuando se caiga no afecte las operaciones, y asi podernos ahorrar el servicio 3 de estructurarla y despues insertarla.
¡Hola! En ningún momento decimos que "es mejor" la estructura que se propone en el video, recuerda que es un curso práctico y entre todos nos hacemos reviews.
Algo que se recalca MUCHO en este curso es: "siempre pregunta a otros qué les parece la estructura que propones", siempre surgirán nuevas ideas y se llegará a una mejor planeación backend.
El profesor da su punto de vista y así es como el considera que mejor funcionaría el sistema, pero la pregunta que haces es muy asertada porque estás proponiendo otra solución, estás proponiendo una idea que podría ser mejor para el sistema y es totalmente válida, recuerda que siempre que hagamos algo debemos preguntarnos "¿por qué?", "¿por qué esto es así?", "¿por qué quiero usar este servicio?", "¿por qué esta estructura me conviene más que la otra?", "¿por qué hacerlo de esta manera y no hacerlo de esta otra?"
Ahora, respondiendo tu pregunta, como te menciono, es solo una propuesta, desde mi punto de vista (y por el conocimiento que tengo en bases de datos), las bases de datos no relacionales suelen ser más rápidas en cuanto inserción se refiere, y las bases de datos relacionales (SQL) son las mejores para hacer búsquedas, además algunas como MySQL tienen motores optimizados para lectura de datos (sacrificando velocidad de escritura), cosa en la que las bases de datos no relacionales no son tan buenas, es más fácil usar SQL para búsqueda de datos (y si metemos índices entonces la velocidad lectura aumenta, pero los índices no se llevan muy bien con la escritura).
Esa es una posible justificación para el sistema que propone el profesor, recuerda que el objetivo es ser rápidos con la lectura de datos, y una base de datos que pueda procesar la lectura de una manera rápida nos ayuda mucho.
Si dejamos una única base de datos que sea de lectura y escritura estamos sacrificando velocidad de lectura para meter escritura también.
Yo más adelante propongo un modelo donde la data vieja se guarda en una tercera base de datos para no sobrecargar las bases de datos de lectura y hacerla más eficiente.
El momento para sincronizar ambas bases de datos depende de cuando tu quieras, yo en lo personal las sincronizaría a las 00:00 horas de cada día 🤔
Repito, hay muchas formas de estructurar los sistemas backend, no hay una forma mejor que otra, en todas las estructuras siempre se sacrificará algo (trade off), lo más importante es siempre preguntarte "¿por qué?", y pedir feedback, pedir un design review para tu design doument ^^
Tomar en cuenta el soporte de Postgresql en su versión XL que corre en clusters, el cual soporta procesamiento masivo en paralelo, datos no estructurados usando key-value de datos tipo JSON ideal para sustituir NoSQL en este diseño propuesto
No lo conocia, gracias por el aporte
Viendo el ejemplo, me viene en mente il patron CQRS, pero es al contrario.
Quando subes los datos(Post) va a un RDBMS e cuando haces la lectura, la haces da un NOSQL.
Que tenga una BBDD NoSQL que inyecta su información cada 24hrs a una BBDD relacional significa que si un editor pública una review esta estará disponible a los usuarios lectores hasta 24hrs despues de su publicación cierto?
curso desactualizado
Yo prefiero Draw.io para hacer diagramas.
Otro requerimiento podria ser, que tan en real-time se necesita la información?
Yo no creo que el cliente quiera esperar una vez al dia para que las bds de lectura se actualicen. Yo creo que en este caso pudiera haber otra función serverless con un trigger a un insert en la base de datos de escritura