Diseño de bajo de nivel de servicio de lectura

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

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

Buenas noches, comparto mi arquitectura para feedback

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!

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": ""
}

recomiendas vm? en vez de docker?