Home
/

Resumen del Proyecto

Sistema de Gestión de Órdenes Basado en Eventos

Plataforma de comercio electrónico distribuida que gestiona el ciclo de vida completo de órdenes de compra con garantías de consistencia eventual en un entorno de microservicios.

Orientado a Eventos
Event Sourcing
Saga Pattern
Microservicios

Problema Resuelto

  • •Gestión del ciclo de vida completo de órdenes de compra
  • •Consistencia eventual en entorno de microservicios
  • •Comunicación confiable entre servicios descentralizados
  • •Compensación distribuida ante fallos
  • •Auditabilidad completa del sistema de pedidos

Arquitectura del Sistema

Order Service

API + Workers

3000

Gestión de órdenes, Event Sourcing, Outbox Worker

Event Store
Outbox Pattern
Deduplication

Inventory Service

Event Consumer

Reservas de stock, gestión de inventario

Stock Management
Reservations

Payment Service

Event Consumer

Procesamiento de pagos, validación

Payment Processing
Validation

REST API

Express + TSOA

HTTP endpoints para clientes

POST /orders
GET /orders/:id
GET /:id/events

outbox-worker

Worker

Publica eventos del outbox a RabbitMQ

Polling cada 5s
Publicación confiable

router.ts

Event Router

Enruta eventos usando Consistent Hashing

Distribución por orderId

workers

Partitioned Workers

Procesan eventos de órdenes

2 particiones
DLQ support
Deduplicación Redis

Patrones de Diseño Implementados

5 Patrones de Diseño

Event Sourcing

Almacena el estado como secuencia de eventos en lugar de estado actual

Audit trail completo
Replay de estado
Debugging temporal

Outbox Pattern

Publica eventos de forma confiable usando tabla outbox

Garantía de entrega
Sin CDC externo
Transaccional

Saga (Coreografía)

Orquestación distribuida mediante mensajes entre servicios

Desacoplamiento total
Escalabilidad horizontal
Fault isolation

Deduplicación

Prevención de procesamiento duplicado con Redis

Idempotencia
Exactly-once semantics
Recovery

Consistent Hashing

Distribución uniforme de eventos entre workers

Balanceo de carga
Escalabilidad
Minimize reshuffling

Infraestructura AWS

Componentes de Infraestructura AWS

19 Items
services-cluster

ECS Cluster

t3.micro • ASG: 1-2

rabbitmq-cluster

ECS Cluster

t3.micro • Fixed: 1

order-service
ALB

ECS Service

Port: 3000 • Public-facing

inventory-service
Service Connect

ECS Service

Internal • Event Consumer

payment-service
Service Connect

ECS Service

Internal • Event Consumer

rabbitmq
Service Connect

ECS Service

Ports: 5672/15672 • Message Broker

ALB
Entry point

Application Load Balancer

Port: 80/443

VPC
AWS VPC

Virtual Private Cloud

AZ A

Service Connect
DNS

Cloud Map

commerce-platform.local

order-service-db
orders + events

RDS PostgreSQL

db.t3.micro • 20GB

inventory-service-db
inventory

RDS PostgreSQL

db.t3.micro • 20GB

payment-service-db
payments

RDS PostgreSQL

db.t3.micro • 20GB

Redis
deduplication

ElastiCache

cache.t3.micro • Port: 6379

Security Groups
Network

5 groups

order-svc, rabbitmq, rds, redis, common

KMS
Encryption

Key Management

RDS + SSM encryption

ECR
Images

Container Registry

3 repos

CloudWatch Logs
Logs

Logging

Log groups per service

SSM Parameter Store
Secrets

Secrets

DATABASE_URL, Redis, RabbitMQ

IAM Roles
Access

ECS Roles

Task Execution + Task Roles

Flujos de Datos

Decisiones de Diseño y Trade-offs

Por qué:Auditabilidad completa, replay de eventos, debugging detallado de estado
Trade-off:Complejidad de implementación, curva de aprendizaje, requiere proyecciones para lecturas eficientes
Alternativas:CRUD tradicional
Por qué:Publicación confiable de eventos sin CDC externo, simple de implementar
Trade-off:Latencia de 5s (polling), no es real-time, requiere workers adicionales
Alternativas:Transaction Outbox con Debezium
Por qué:Desacoplamiento total entre servicios, escalabilidad horizontal
Trade-off:Difícil de rastrear, debugging complejo, riesgo de ciclos infinitos
Alternativas:Saga Orquestada (orquestador central)
Por qué:Testabilidad, independencia de frameworks, facilidad para cambiar tecnología
Trade-off:Boilerplate adicional, curva de aprendizaje, más archivos
Alternativas:MVC, Layered Architecture
Por qué:Aislamiento de fallos, independencia de equipos, cumplimiento de microservicios
Trade-off:Consistencia eventual compleja, joins distribuidos imposibles, más operacional
Alternativas:Base de datos compartida (monolito)

Consideraciones de Seguridad

Autenticación

NO IMPLEMENTADO

No se observa JWT, API keys, ni OAuth

Mitigación: Implementar JWT tokens, API keys

Autorización

NO IMPLEMENTADO

Cualquier cliente puede consultar cualquier orden

Mitigación: Autorización por customerId

Gestión de Secretos

DATABASE_URL

AWS SSM

RabbitMQ credentials

AWS SSM

Redis URL

AWS SSM

Vulnerabilidades Identificadas

Data exposure

Mitigación: Filtrar respuestas HTTP

SQL Injection

Mitigación: Queries parametrizadas

Rate limiting

Mitigación: API Gateway rate limit

Limitaciones y No-Objetivos

Lo que el Sistema NO Hace

Autenticación/Autorización

Cualquier cliente puede acceder a cualquier recurso

Catálogo de productos

Asume productId existentes

Gestión de usuarios

Asume customerId existentes

Notificaciones (email/SMS)

Podría extenderse con webhook

Reporting/Analytics

Requiere proyecciones adicionales

Restricciones Técnicas

Workers fijos (2 particiones)

Throughput limitado, requiere reconfiguración

Polling 5s en Outbox

Latencia mínima de 5s para eventos

PostgreSQL single-node

Punto único de fallo en persistencia

Event Store crece indefinidamente

Requiere estrategia de archivado