No tienes acceso a esta clase

隆Contin煤a aprendiendo! 脷nete y comienza a potenciar tu carrera

Dise帽o de bajo de nivel de servicio de lectura

22/25
Recursos

Aportes 12

Preguntas 1

Ordenar por:

驴Quieres ver m谩s aportes, preguntas y respuestas de la comunidad?

o inicia sesi贸n.

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:

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 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?

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

Que pocos comentarios, supongo que no es uno delos cursos mas populares, no saben lo importante que es el diseno

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 鈥淕etReviewCamera鈥 el cual solicita informaci贸n al Cache 鈥淓lastiCache for Redis鈥 y si en caso de no existir informaci贸n solicitada en Cache se realizara una b煤squeda en BD 鈥淒ynamo 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:

Buenas noches, comparto mi arquitectura para feedback

{
  "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":[]
			}
		}
	}
}

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!

recomiendas vm? en vez de docker?

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": "[email protected]",
      "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": ""
}