Descripción Actualizada del Diseño del Sistema Propuesto

El sistema de Gestión de Inventario en Tiempo Real para una Cadena de Tiendas Minoristas está diseñado para
superar las limitaciones del sistema legacy actual. La solución se basa en una arquitectura de microservicios,
soportada por herramientas modernas para garantizar sincronización en tiempo real, alta disponibilidad y
escalabilidad. A continuación, se describen los subsistemas clave del diseño:

1. Subsistema de Canales

Este subsistema conecta los diferentes puntos de interacción del sistema con los usuarios finales y el backend:

● POS (Point of Sale): Representa los puntos de venta físicos donde se registran ventas y devoluciones.
● Sistema de E-commerce: Plataforma que gestiona las compras en línea, mostrando disponibilidad de
inventario en tiempo real.
● Warehouse Interface: Sistema utilizado por los administradores de almacenes para gestionar el stock y realizar
consultas.
 ● Amazon API Gateway: Centraliza y enruta todas las solicitudes de los canales hacia los microservicios
correspondientes.

2. Subsistema de Microservicios

Los microservicios encapsulan funcionalidades específicas y desacopladas:

● Microservicio de Inventario:
○ Gestiona el inventario central en tiempo real.
○ Procesa transacciones (ventas, devoluciones) provenientes de los canales.
○ Actualiza los niveles de stock en la base de datos principal y en Redis.
● Microservicio de Sincronización:
○ Consume eventos de los tópicos de Kafka relacionados con transacciones POS, e-commerce y
actualizaciones de inventario.
○ Actualiza el inventario global con base en estos eventos.
○ Procesa datos enviados desde el sistema legacy a través de Apache NiFi.
● Microservicio de Alertas:
○ Detecta condiciones críticas como inventario bajo, alto o inconsistencias.
○ Genera notificaciones (vía email, SMS) basadas en reglas configuradas.
○ Utiliza Elasticsearch para registrar eventos y realizar consultas rápidas.

Tecnologías: Implementados en Spring Boot, diseñados para despliegues en AWS (EC2, RDS).

3. Subsistema de Almacenamiento de Datos

El sistema emplea dos tipos de almacenamiento para cubrir necesidades de persistencia y velocidad:

● Base de Datos Relacional (PostgreSQL):

○ Almacena datos estructurados como productos, inventario, transacciones y alertas.
○ Relaciona las principales entidades del sistema (items, almacenes, clientes).
● Base de Datos en Caché (Redis):
○ Permite consultas rápidas para datos frecuentemente utilizados, como el stock disponible en tiempo
real.
○ Reduce la carga de la base de datos principal.
4. Subsistema de Sincronización de Datos

Este subsistema garantiza la consistencia y sincronización en tiempo real de los datos:

● Apache Kafka:
○ Utiliza tópicos como pos_transactions, ecommerce_transactions, inventory_updates,
low_stock, insufficient_stock y high_stock.
○ Orquesta la comunicación asincrónica entre los microservicios, asegurando alta disponibilidad.
● Apache NiFi:
○ Procesa los batch nocturnos generados por el sistema legacy.
○ Convierte los datos batch en eventos que son publicados en los tópicos de Kafka.
○ Permite una integración eficiente con el sistema existente.

5. Subsistema de Monitoreo y Observabilidad

Este subsistema supervisa el comportamiento del sistema para garantizar su estabilidad y rendimiento:

● Elasticsearch:
○ Almacena y permite consultas sobre los logs generados por los microservicios.
○ Registra alertas relacionadas con niveles de inventario y errores en el sistema.
● Kibana:
○ Proporciona visualización gráfica de métricas clave, como el rendimiento de los microservicios y el
estado del inventario.
● Alerting System:
○ Detecta anomalías operativas y envía notificaciones a los administradores.

6. Subsistema de Infraestructura

Este subsistema soporta el despliegue, la operación y la escalabilidad del sistema:

● AWS (Amazon Web Services):

○ Maneja la infraestructura base utilizando EC2, RDS, S3 y servicios gestionados como Amazon
OpenSearch Service.
○ Despliega los microservicios en contenedores con escalabilidad automática.
● Spring Boot:
○ Base para el desarrollo de microservicios, integrándose con Kafka, Redis, PostgreSQL y Elasticsearch.
7. Subsistema de Integración con el Sistema Legacy

Este subsistema asegura una transición gradual y sin interrupciones hacia el nuevo sistema:

● Apache NiFi:
○ Consume los batch nocturnos generados por el sistema legacy.
○ Publica eventos en los tópicos de Kafka para sincronizar el inventario en tiempo real.
● Migración de Datos Históricos:
○ Se realiza de forma incremental, priorizando los datos más relevantes para las operaciones en tiempo
real.
○ El sistema legacy permanece operativo durante la transición, permitiendo un cambio gradual.

Este diseño modular y distribuido garantiza que la solución pueda manejar el volumen actual de operaciones, mejorar
la precisión del inventario y escalar para satisfacer demandas futuras. Además, integra herramientas modernas como
Kafka y NiFi para sincronización de datos y AWS para soporte de infraestructura.

Diseño de alto nivel de la base de datos.

El modelo de base de datos actualizado para el sistema de inventario en tiempo real incorpora las siguientes entidades
principales, sus atributos y relaciones clave, diseñado para soportar una gestión eficiente y escalable:

Entidades Principales y Relaciones:

1. Item (Producto):

○ Atributos:
■ item_id (PK): Identificador único del producto.
■ name: Nombre del producto.
■ description: Descripción detallada.
 ■ price: Precio del producto.
■ category: Categoría del producto.
○ Relaciones:
■ Cada producto está relacionado con una entrada en Inventory.
2. Inventory (Inventario):

○ Atributos:
■ inventory_id (PK): Identificador único del inventario.
■ item_id (FK): Identificador del producto asociado.
■ quantity: Cantidad disponible del producto.
■ warehouse_id (FK): Almacén donde se encuentra el producto.
○ Relaciones:
■ Relación 1 a N con Alerts para identificar problemas de stock.
■ Relación 1 a N con Warehouse para definir las ubicaciones físicas.
3. Point_of_Sale (POS):

○ Atributos:
■ pos_id (PK): Identificador único del punto de venta.
■ location: Ubicación del punto de venta.
■ manager_name: Nombre del gerente encargado.
○ Relaciones:
■ Se conecta con múltiples registros en POS_Events.
4. POS_transaction (Eventos del POS):

○ Atributos:
■ pos_transaction_id (PK): Identificador único del evento.
■ pos_id (FK): Identificador del punto de venta asociado.
■ item_id (FK): Producto involucrado en el evento.
■ event_type: Tipo de evento (venta, devolución, etc.).
■ quantity: Cantidad afectada por el evento.
■ created_date: Marca de tiempo del evento.
■ customer_id (FK): Cliente que realizó la transacción.
○ Relaciones:
■ Relación N a 1 con Point_of_Sale y N a 1 con Item.
5. E-commerce_Transactions (Transacciones de E-commerce):
 ○ Atributos:
■ ec_transaction_id (PK): Identificador único de la transacción.
■ customer_id (FK): Cliente que realizó la transacción.
■ item_id (FK): Producto adquirido.
■ quantity: Cantidad adquirida.
■ status: Estado de la transacción.
■ created_date: Fecha y hora de la transacción.
○ Relaciones:
■ Relación N a 1 con Item y N a 1 con Customer.
6. Alerts (Alertas):

○ Atributos:
■ alert_id (PK): Identificador único de la alerta.
■ inventory_id (FK): Inventario asociado.
■ alert_type: Tipo de alerta (bajo stock, inconsistencias, etc.).
■ severity: Grado de severidad de la alerta.
■ created_date: Marca de tiempo de la alerta.
○ Relaciones:
■ Relación 1 a 1 con Inventory.
7. Customer (Cliente):

○ Atributos:
■ customer_id (PK): Identificador único del cliente.
■ name: Nombre del cliente.
■ email: Correo electrónico.
■ phone: Teléfono.
○ Relaciones:
■ Relación 1 a N con E-commerce_Transactions.
8. Warehouse (Almacén):

○ Atributos:
■ warehouse_id (PK): Identificador único del almacén.
■ name: Nombre del almacén.
■ location: Ubicación del almacén.
○ Relaciones:
■ Relación 1 a N con Inventory.
 Resumen de Relaciones:

● 1 a 1:
○ Alerts con Inventory.
● 1 a N:
○ Item con Inventory.
○ Warehouse con Inventory.
○ Customer con E-commerce_Transactions.
○ POS con POS_Transactions.
● N a N:
○ Item con E-commerce_Transactions y POS_Transactions.

Beneficios del Modelo:

1. Integridad de Datos: Las claves foráneas aseguran relaciones consistentes entre tablas.
2. Rendimiento: Redis optimiza el acceso rápido a datos del inventario en tiempo real.
3. Escalabilidad: PostgreSQL maneja volúmenes altos de datos relacionales.
4. Extensibilidad: Soporta integraciones futuras con nuevas características y subsistemas.

Este diseño permite mitigar los problemas actuales del sistema legacy, asegurando sincronización en tiempo real y
acceso eficiente a datos críticos para la operación de la cadena minorista.

Descripción del Proceso de Sincronización de Datos

 A. Descripción del Proceso de Sincronización de Datos para el Sistema Legado

Contexto del Sistema Legado: El sistema legacy se basa en un procesamiento batch nocturno para consolidar y
sincronizar datos de inventario, ventas y devoluciones. Este enfoque resulta en una alta latencia y genera
inconsistencias en la información disponible para las plataformas operativas. La modernización busca convertir
estos datos batch en eventos procesables en tiempo real mediante tecnologías como Apache NiFi y Kafka.

Flujo de Sincronización:

1. Generación de Datos Batch:

○ El sistema legacy recopila datos operativos (ventas, devoluciones, inventario) durante el día.
○ Cada noche, estos datos se consolidan en archivos batch (JSON, CSV o XML) mediante procesos
programados como Cron Jobs o Task Scheduler.
○ Los archivos se almacenan en ubicaciones accesibles, como:
■ Sistemas de archivos compartidos (NFS).
■ Almacenamiento en la nube (AWS S3 o Azure Blob Storage).
2. Procesamiento de Batch con Apache NiFi:

○ Extracción: NiFi detecta nuevos archivos batch y los carga en su flujo de trabajo.
○ Transformación:
■ Divide los archivos en eventos individuales.
■ Enriquecimiento de datos: añade metadatos como timestamps y normaliza estructuras.
 ○ Publicación en Kafka:
■ Los eventos transformados se envían a tópicos específicos:
■ inventory_updates: Datos de inventario.
■ pos_transactions: Ventas en tiendas físicas.
■ ecommerce_transactions: Transacciones online.
3. Procesamiento en el Microservicio de Sincronización:

○ Consume eventos desde los tópicos de Kafka.

○ Valida y estructura los datos.
○ Actualiza las bases de datos:
■ Redis: Para consultas rápidas de inventario en tiempo real.
■ PostgreSQL: Como almacén principal para análisis histórico.
4. Distribución de los Datos:

○ Los datos sincronizados se utilizan para actualizar sistemas conectados (e.g., plataformas de e-
commerce y POS).

Resultados:

● La información del sistema legacy se integra en tiempo real con los sistemas modernos.
● Se eliminan las inconsistencias generadas por las actualizaciones nocturnas.

B. Descripción del Proceso de Sincronización de Datos para Canales en Tiempo Real

(POS, E-commerce y Warehouse Interface)

Contexto de los Canales Modernos: En la arquitectura modernizada, los datos son generados directamente por
los canales en tiempo real (POS, e-commerce y warehouse interface). Cada canal produce eventos que
representan operaciones como ventas, devoluciones, pedidos o movimientos de inventario.

Flujo de Sincronización:

1. Generación de Eventos por los Canales:

○ POS (Point of Sale):

 ■ Cada venta o devolución genera un evento (SALE, RETURN) enviado al tópico
pos_transactions de Kafka.
○ E-commerce:
■ Los pedidos, devoluciones y cancelaciones generan eventos (ORDER, RETURN, CANCEL)
enviados al tópico ecommerce_transactions.
○ Warehouse Interface:
■ Cada movimiento de inventario (recepción, transferencia, salida) genera eventos enviados al
tópico inventory_updates.
2. Publicación en Apache Kafka:

○ Los eventos son publicados directamente por los canales en sus respectivos tópicos:
■ pos_transactions.
■ ecommerce_transactions.
■ inventory_updates.
3. Procesamiento en el Microservicio de Sincronización:

○ Consumo de Eventos:
■ El microservicio escucha en tiempo real los tópicos relevantes.
○ Transformación y Validación:
■ Los datos son validados y enriquecidos según reglas de negocio.
○ Actualización de Bases de Datos:
■ Redis: Almacena los datos más consultados (e.g., niveles actuales de inventario).
■ PostgreSQL: Registra las transacciones y movimientos de inventario para análisis histórico.
4. Notificaciones y Alertas:

○ Si se detectan condiciones críticas (e.g., inventario bajo, inconsistencias), los eventos se publican
en el tópico alerts.
○ El microservicio de alertas consume este tópico y genera notificaciones hacia los sistemas
relevantes.
5. Distribución de Datos Sincronizados:

○ Los sistemas conectados (e.g., e-commerce, POS) consultan Redis para obtener información
actualizada.

Resultados:
 ● La sincronización en tiempo real asegura consistencia y disponibilidad inmediata de datos en todos los
sistemas.
● Los tiempos de respuesta mejoran drásticamente, eliminando los problemas de desactualización.

Comparativa: Legacy vs Canales en Tiempo Real

Aspecto Sistema Legacy Canales en Tiempo Real

Latencia Alta (hasta 24 horas por lotes Baja (procesamiento en tiempo real).
nocturnos).

Generación de Archivos batch consolidados. Eventos individuales generados por

datos los canales.

Tecnologías clave Apache NiFi, Kafka, Kafka, Redis, PostgreSQL.

PostgreSQL, Redis.

Escalabilidad Limitada por procesamiento Alta, soporta grandes volúmenes de

batch. eventos.

Ahora basado en la información anterior genera la descripcion para este punto:

“Propuesta de tecnologías e integraciones a utilizar y justificación. (Lenguajes,Framework, Librerías, Motor BD, Cloud,
Doc, Infra, SAS)”