Diseño de Servicios de Lectura Escalables y Stateless

Clase 22 de 25 • Curso Práctico de Arquitectura Backend

Resumen

¿Cómo abordar el diseño de un servicio de lectura?

El reto del diseño de un servicio de lectura es un desafío fascinante y crucial en el mundo de la arquitectura de sistemas back end. Los servicios deben construirse sobre una base sólida que asegure que la información que hemos publicado a través del servicio de escritura se recupere de manera eficiente. Este reto te invita a diseñar un documento de diseño a bajo nivel, detallando cada aspecto de la implementación del servicio de lectura. Es fundamental elaborar este trabajo con esmero, buscando retroalimentación varias veces para mejorar el diseño. ¡Veamos cómo lograrlo!

¿Qué elementos deben incluirse en el diseño de la entidad de reseña?

Para que el servicio de lectura funcione correctamente, es esencial definir con claridad y precisión el diseño de la entidad de reseña (review). Este diseño es el principal entregable y debe satisfacer las necesidades del cliente. Algunos puntos a considerar son:

Detallar la entidad: Proporcionar una definición clara de qué elementos conforman la reseña.
Método de extracción de información: Definir cómo se extraerá la información desde la base de datos no relacional.
Transformación y regreso de los datos: Describir la manera en que los datos serán transformados y devueltos a través de una petición GET.
Incluir todos los componentes necesarios: Desde bases de datos adicionales hasta servicios cache, serverless o dedicados.

¿Cuáles son las consideraciones clave al diseñar la arquitectura?

La arquitectura debe estar bien pensada para servir de la mejor manera a millones de usuarios. Algunas recomendaciones incluyen:

Elegir un diseño escalable: Debe ser capaz de manejar millones de lecturas simultáneamente.
Incluir un servicio stateless: Sugiere que el servicio de lectura no debe guardar estado, permitiendo escalar horizontalmente utilizando máquinas virtuales. Esto implica que ninguna VM debe guardar operaciones de almacenamiento.
Conectar adecuadamente con la base de datos no relacional: La base de datos es la fuente de información y debe ser eficiente.

¿Cómo determinar el modelo de datos y el payload del JSON?

Definir el modelo de datos es una parte crucial del proceso de diseño. Debe incluir ejemplos claros de cómo se verá el payload de JSON que el API devolverá. Al desarrollar este modelo:

Proporciona ejemplos JSON: Ayuda al cliente a entender los datos que recibirá.
Define claramente el API GET: Este diseño mostrará lo que el cliente puede esperar al consumir el API.

¿Qué tecnologías pueden ser utilizadas?

El diseño a bajo nivel debe incluir detalles sobre las tecnologías y proveedores que se utilizarán. Aunque el lenguaje de programación es opcional, es necesario definir:

Proveedor cloud: Escoger el entorno o servicio cloud que mejor se adapte a las necesidades del proyecto.
Tecnologías específicas para el sistema: Determinar las herramientas más eficaces para cada parte del servicio.

Para concluir, hay que utilizar todos los recursos a nuestra disposición y aplicar la creatividad y el análisis propio para desarrollar una solución única. Esto enriquecerá tu capacidad de creación y te preparará mejor para enfrentar desafíos futuros en el campo de la arquitectura back end. ¡Adelante con la implementación de este reto!

Carlos Eduardo Gomez García

teacher•

Stateless (sin estado)

Se refiere a que cada solicitud será única y no tendrá ningún tipo de relación con alguna solicitud anterior, es decir, no se va a guardar nada, cada transacción iniciará desde 0. Para poner una analogía, imagina una computadora SIN disco duro, cada proceso que haga esta computadora no se va a guardar, imagina que por cada proceso, enciendes la computadora, hacer el proceso y luego la apagas de nuevo, eso es stateless. . En cambo, stateful sí que puede guardar cosas y comunicarse con procesos anteriores, usar datos generados de un proceso para hacer otro proceso.

Horizontal Scaling (escala horizontal)

. Anteriormente, cuando un sistema crecía y empezaban a incrementar la cantidad de solicitudes al servidor en miles de solicitudes por segundo solíamos pensar que simplemente teníamos que agregarle un mejor CPU, más memoria RAM, más discos duros, mejorar la conexión a internet... ¿Pero qué pasaba si mi demanda aumentaba a millones, pero yo ya tenía el servidor más potente del mundo y no podía agregarle nada más y aun así no abastecía para satisfacer millones de usuarios? A esto se le llama escala vertical, sin embargo, poco a poco se fue adoptando el concepto de escala horizontal en donde, en lugar de tener un servidor superpotente con el mejor procesador y teras de RAM, podemos tener varias computadoras atendiendo esas miles solicitudes, y si la demanda crece a millones, nos basta con simplemente agregar más computadoras que puedan atenderlas.

De nuevo, Freddy tiene un video explicando cómo se escalan: @youtube

Tomas Bond

student•

excelente

Francisco Serrato Jiménez

student•

Excelente aportación profe ++RetaxMaster++, para complementar dar clic al link.

Raul Enrique Torres Reyes

student•

Como bien menciona Jorge solo con retroalimentación podremos hacer las cosas mejor, así que aquí esta mi ejemplo (espero sus comentarios)

El diagrama lo realice poniendo las cosas que conozco y he utilizado

El frontend se conectaría a un servidor NGINX el cual dirigiría las peticiones dependiendo del método de request que se realice.
Si es un nuevo review(POST) este será tratado por un django api rest que vive en un contenedor de docker y que guardara los datos dentro de una base de datos en postgresql.
Esta base de datos maestra realizara una replicación a otro servidor de postgresql, esta replicación será de forma asíncrona con esto ganamos velocidad en la escritura aunque no aseguramos que los datos estén inmediatamente disponibles en el servidor de replica.
Si los usuarios quieren consultar un review(GET) este será tratado en otro api rest que también es un contenedor y se encuentra un servidor diferente, este se conecta a la base de datos postgresql que es la replica de la base de datos maestra.

Notas: Utilice una base de datos relacional como postgresql porque no tengo mucha experiencia utilizando bases de datos nosql además de que en teoría no tenemos millones de editores realizando reviews al mismo tiempo así que la velocidad de escritura no tendría diferencia significativa contra una base de datos nosql.

El proyecto de api rest de django es el mismo tanto para el de escritura como para el de lectura, por eso los puse en un contenedor para poder desplegarlo de manera mas fácil en ambos lados.

**Algo que me surge como duda es, que podría hacer en este caso: ** ¿Si un Editor escribe su review e inmediatamente quiere consultarla, no podemos asegurar que ya se encuentre guardada en el servidor de replica y quizá cuando la consulte no exista aun y le de la sensación de que no se guardo?

J. Sebastián Botello. H.

student•

Podrías manejar "la sensación" con estados, creas servicios que te alerten cuando algo pasa.. En un ambiente "soñado" las replicas son inmediatas y esto no sería un lio. Creo que sería la forma de resolverlo.

Julio Cesar Arbieto Chavez

student•

Carlos Eduardo Gomez García

teacher•

Vale, aquí está mi práctica, realmente no sé cómo puedo ser más específico con eso, ¿debería poner los nombres de las funciones a llamar? . Básicamente el front-end manda a llamar servidores stateless, que contienen el API bajo Laravel procesando la solicitud, este se conecta a una base de datos alojada en GCP. . El servicio retornaría los datos del review que fue pedido, pero product solo retornará el id del producto, para obtener el resto de la información se necesita hacer otra petición hacia products:

{
	"id": 1,
	"content": {
		"title": "El titulo del review",
		"autor": "El autor del review",
		"content": "El contenido del review",
		"product": {
			"id": 1
		}
	}
}

Acepto feedback:D

Jair Israel Avilés Eusebio

student•

Buen diseño. Hablando sobre el payload, creo que seria excelente que se regrese los detalles completos de la product, para ahorrar un request. Esto en terminos de implementacion podria ser que en tus servicio de GET sea implementado con un ORM configurando las entidades que se relacionan.

Julio Cesar Arbieto Chavez

student•

Adjunto imagen plasmando la arquitectura según el requerimiento solicitado, paso a explicar:

Para realizar el procesos de leer los registro desde el Front-End, en este caso tenemos un cliente PWA React js, que lee un Api Gateway que expone un método (Serverles Function) desarrollado Net Core 3.1 C# - le denomine “GetReviewCamera” el cual solicita información al Cache “ElastiCache for Redis” y si en caso de no existir información solicitada en Cache se realizara una búsqueda en BD “Dynamo DB”, en este caso decidí utilizar esta BD por que es rápida, obviaste esto depende a la estructura o diagrama de BD. El cache nos ayudara en obtener inflacionario en menos latencia/ tiempo. Con esto reduciría poco lo que es el costo de consumo de BD, asumiendo que esta Api sera leída por millones de usuarios en tiempo real. Ademas de ello cabe mencionar que el Lambda Serverles es Auto escalable y es Algo que se requiere cuando trabajamos con Millones de Usuarios. A la vez utilizaría el Cache que tiene el Api Gateway ya que seria genial para tener menos consumo del Lambda. La Structura del Json Como Response del Method GetReviewCamera seria la siguiente:

Julio Cesar Arbieto Chavez

student•

{
  "status": "OK",
  "message": "",
	"review": {
		"id": 1,
		"content": {
			"title": "The title of the review",
			"author": "The author of the review",
			"content": "The content of the review",
			"product": {
				"id": 1,
				"name": "name product",
				"description":"Description of the product",
				"manufacturer":"Manufacturer of the product",
				"sku": "",
				"feature":[]
			}
		}
	}
}

Jennifer Cano

student•

Buenas noches, comparto mi arquitectura para feedback

Carlos Fernando Aguilar González

student•

Carlos Eduardo Gomez García

teacher•

Hay 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

Rodrigo Hernández

student•

Hola @RetaxMaster te aclaro algunos puntos de acuerdo a mi experiencia:

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 :)

Capacitacion 2

student•

Hola, que tal? dejo un link de Drive que lleva a la carpeta de la tarea: https://drive.google.com/drive/folders/1oskwcb9em5EqhnyriVk5rcGWR-ME37Yy?usp=sharing Gracias, saludos!

Junior Ignacio Romero Quiñones

student•

Esta bueno el curso. Muchas gracis por compartir tus conocimientos.

Carlos Eduardo Magallon Zepeda

student•

Este es un esquema prácticamente desde cero, sin serverless ni demás cosas. Opcionalmente se podría agregar otra capa al frente como un balanceador de carga, aunque yo creo que con la cache debería bastar o reemplazar Django por FastAPI y SQLAlchemy, ya que soportan muchas más peticiones por minuto.

No he usado bases de datos NoSQL así que no las agregué

{
  "status": "Ok",
  "review": {
    "id": 1,
    "title": "Title",
    "author": {
      "id": 1,
      "profileImg": "[].jpg",
      "email": "user@example.org",
      "username": "username",
      "accountType": "basic"
    },
    "content": "Content",
    "created": "01-01-2000",
    "modified": "01-01-2000",
    "product": {
      "id": 1,
      "title": "Title",
      "category": "Category",
      "description": "Description",
      "manufacturer": "Manufacturer",
      "SEOTitle": "SEO title",
      "SEODescription": "SEO description",
      "averagePrice": 1,
      "imageUrl": "[].jpg",
      "sku": "sku",
      "created": "01-01-2000",
      "modified": "01-01-2000",
      "affiliateLink": "[].com"
    }
  },
  "error": ""
}

Francisco Javier Pineda Giraldo

student•

Que bueno que todos saben tanto, Yo, seguiré aprendiendo con las clases y todos sus comentarios, no solo debo Aprender sobre todas las herramientas sino echarme al agua codificando el proyecto propuesto

Junior Aguilera

student•

recomiendas vm? en vez de docker?

Moisés Abraham Croes Gómez

student•

Personalmente me gusta mas la idea de usar Docker en un Web App de Azure o el servicio de Kubernetes, sobretodo este ultimo creo que es totalmente compatible con la característica de escalabilidad que buscamos

William Schnaider Torres Bermon

student•

Hay casos de casos, pero en la mayoria de las veces un entorno contenerizado resulta más ventajoso. Además, los servicios disponibles en la nube que trabajan con contenedores ofrecen increibles herramientas.