Se propone una solucion diferente a la que habia anteriormente, dado las falencias que la misma posee.
La solucion anterior presentaba un sistema de pulling, donde el client hacia "pulls" cada un cierto tiempo a la base de datos central y luego aplicaba los cambios. El problema de esto es la fragilidad a quedar desincronizados y el tiempo de espera para obtener los datos era demasiado aumentando asi que los datos queden con discrepancias.
Esta solucion propone una mirada diferente, en vez de ser el cliente quien "pide" los cambios, se subscribe a una cola de mutaciones que la base de datos central (Inventory Management Service) produce como consecuencias a interacciones con su API.
A partir de esta solucion nacen las "mutations" que simplemente son registros de eventos que ocurrieron sobre la base de datos central. Estos eventos son propagados utilizando RabbitMQ como broker de manera que llegue a todos los clientes conectados que se encuentran a la espera de recibir una mutacion.
Ademas, el hecho de subscribirse a los eventos en vez de periodicamente pedirlos produce que el cliente obtenga los nuevos cambios muchisimo mas rapido (Pasando de 15 min a menos de 1s). Por lo tanto la fragilidad de la desincronizacion disminuye notoriamente.
Al tener una lista ordenada por timestamp sobre los cambios que fueron produciendose, el cliente puede replicarlos de manera ordenada y en caso de fallar en cierto punto, puede reestablecerse a partir de la ultima mutacion que aplicó. De esa manera, se disminuye la probabilidad de que haya inconsistencias entre lo que la base central tiene con lo que cada cliente tiene registrado.
Aqui el diagrama.
El cliente es un servicio que se encuentra a la espera de mutaciones. Posee la capacidad de entender lo que es una mutacion y aplicarla a su base de datos local.
Que pasa si el cliente se cae? Cuando el cliente se cae y se reestablece, realiza una consulta al servicio central (Inventory Management Service) pidiendo todas las mutaciones a partir de una cierta fecha.
-
Si la base de datos esta vacia, la ultima fecha que tiene el cliente es nula por lo tanto pide las filas de la base de datos central. Este seria el caso de que se inicia un nuevo cliente.
-
Si la base de datos tiene datos, se toma el timestamp mas grande (cuya representacion equivale a la ultima mutation recibida) y se pide las mutations a partir de ese timestamp.
Aqui el diagrama.
La API central (Inventory Management Service) posee autenticacion para aquellos endpoints que producen cambios, es decir, POST, PUT y DELETE. El jwt a usar se puede encontrar en run.md donde este es a solo modo de demostracion un jwt basico sin expiracion ni nada particular.
Simplemente se realizó para similar un entorno mas real.
Se utilizaron las siguientes tecnologias para realizar este desafio.
-
.NET para el Store Client y Inventory Management Service
- Aqui se desarrollaron dos API mas una libreria para usar modelos comunes.
- Se utilizo Central Package Manager para manejar los paquetes desde un unico lugar
- Se realizaron pruebas de codigo de integracion.
-
RabbitMQ como broker el envio de mensajes entre el servicio central y los clientes. Particularmente, este broker se encuentra en formato Cloud en Azure. Se utlizo https://api.cloudamqp.com/ ya que provee un FREE Tier para poder aprender y probar pequeñas cosas.
- Se utilizo un Exchange de tipo Fanout para que el mensaje llegue a todos los clientes.
-
Docker para facilitar la ejecucion de toda la arquitectura sin necesidad de descargar .NET
- Se dockerizaron ambos proyectos
- Se creo un
docker-compose.ymlpara facilitar el startup.
-
Sqlite como base de datos in-memory para persistencia
-
ChatGPT para mejoras, dudas y automatizacion de tests.
La arquitectura propuesta no realiza consultas directamente a una LLM. Sin embargo, se utilizo la LLM como asistente al desarollador para cubrir ciertos huecos donde la AI podia asistir, automatizar y corregir.
Una de las mejoras a realizar es el uso de gRPC para la comunicacion entre servicios, esto haria que sea aun mas rapido cuando el cliente inicia su primer interaccion con el servidor.
Otra mejora, es la configuracion correcta de CORS para solamente permitir consultas desde ciertos origenes.
El uso de HTTPS mejoraria la seguridad de los endpoints.