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.
Introducción a conceptos
Arquitectura de Backend: Diseño e Implementación de Sistemas Avanzados
Conceptos Fundamentales de Back End en Arquitectura Web
Sistemas Monolíticos vs. Distribuidos en Arquitectura Backend
Componentes de un Sistema Backend Distribuido
Conexión de Componentes Backend mediante APIs
Diseño e Implementación de Sistemas Backend Prácticos
Arquitectura y planeación
Definición de Requerimientos de Negocio para Desarrolladores Backend
Creación de Documentos de Diseño de Software
Creación de Documentos de Diseño en Markdown para Proyectos de Software
Revisión Efectiva de Documentos de Diseño en Equipo
Diseño de Arquitectura de Sistemas Distribuidos
Diseño de Sistemas: Documentación de Bajo Nivel y Pruebas
Planificación de Integración Continua y Rollout de Software
Definición y aplicación del concepto "Code Complete" en proyectos software
Decisiones en Diseño de Sistemas Basados en Requerimientos del Negocio
Desarrollo e implementación
Desarrollo e Implementación de Sistemas Backend
Diseño de Entidades para Reseñas de Cámaras y Productos
Diseño e Implementación de Interfaces en C para Productos y Reseñas
Desarrollo de Pruebas Unitarias con TDD en C#
Implementación de pruebas unitarias con TDD en proyectos de software
Desarrollo de un Sistema de Reseñas en Azure
Challenges
Diseño de Servicios de Lectura Escalables y Stateless
Diseño e Implementación de un Servicio de Autenticación
Escalabilidad: Implementación de Throttling y Retry Policy
Conclusión
Preparación Profesional para Desarrolladores Back End Avanzados
No tienes acceso a esta clase
¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera
Si ya tienes una cuenta,
Diseño de Arquitectura de Sistemas Distribuidos
11/25¿Cómo elaborar la arquitectura del sistema?
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.
Aportes 14
Preguntas 2
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
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.
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
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.
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
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.
Este curso debería estar en la ruta backend
jaja, tiro la chapa ahora si, saco el faang
¿Quieres ver más aportes, preguntas y respuestas de la comunidad?