Arquitectura del Sistema - Diagramas Completos
Arquitectura de Alto Nivel
Este diagrama muestra todos los componentes principales y cómo se comunican:
Patrones de Comunicación
1. Cliente → API (REST)
Usado para: Todas las operaciones CRUD, login, transacciones, etc.
2. Cliente ↔ WebSocket (Tiempo Real)
Usado para: Market data, chat, notificaciones en tiempo real.
3. Servicio → Lambda (Invocación)
Usado para: Creación de wallets, envío de transacciones.
4. Monitor → Blockchain (Polling)
Usado para: Detectar transacciones entrantes.
5. Webhook Externo → Sistema
Usado para: Webhooks de Bybit, Manteca, Bridge.
Arquitectura de Seguridad (Capas)
Flujo de Datos: Transacción Completa
Arquitectura de Datos
Relaciones clave:
- Un User tiene múltiples Wallets
- Una Wallet tiene múltiples Transactions
- Un User puede tener múltiples Orders
- Sessions se guardan en Redis (temporal)
- Rate Limits en Redis (ultra-rápido)
- Pub/Sub en Redis para eventos en tiempo real
Escalabilidad Horizontal
Estrategia de escalado:
- Servicios: Se pueden replicar fácilmente (Docker)
- Redis Pub/Sub: Coordina entre múltiples instancias
- MongoDB Replica Set: Alta disponibilidad
- Load Balancer: Distribuye tráfico equitativamente
Decisiones Arquitectónicas Explicadas
¿Por qué Pub/Sub en Redis?
Problema: Si tienes múltiples instancias de WS Service, ¿cómo envías un mensaje a todos los clientes conectados?
Solución: Redis Pub/Sub actúa como "broadcaster":
- Service A publica mensaje en canal
notifications:user_123 - Todas las instancias WS escuchan ese canal
- La instancia que tiene al usuario conectado le envía el mensaje
Sin esto: Solo la instancia que recibe el evento podría notificar al usuario.
¿Por qué separar Monitors de Services?
Razones:
- Responsabilidad única: Monitors solo escuchan blockchain
- Escalabilidad: Puedes escalar monitors independientemente
- Tolerancia a fallos: Si un monitor falla, los servicios siguen funcionando
- Optimización: Monitors pueden tener su propio rate limiting con RPCs
Alternativa descartada: Integrar monitoring dentro de Wallet Service (demasiado acoplado).
¿Por qué Lambda para Wallets?
Razones:
- Seguridad: Cada ejecución es aislada
- Costo: Solo pagas cuando se crea una wallet (poco frecuente)
- Escalabilidad automática: AWS se encarga
- Sin estado: No necesita memoria entre ejecuciones
Alternativa descartada: Endpoint en Wallet Service (más complejo de escalar).
Puntos Críticos del Sistema
Single Points of Failure (SPOFs)
| Componente | Impacto si falla | Mitigación |
|---|---|---|
| MongoDB | Sistema completo cae | Replica Set con 3 nodos |
| Redis | Sin sesiones ni cache | Redis Sentinel o Cluster |
| Auth Service | No se puede login | Múltiples instancias + LB |
| WS Service | Sin tiempo real | Múltiples instancias + Pub/Sub |
Cuellos de Botella
| Componente | Límite | Solución |
|---|---|---|
| Blockchain RPCs | Rate limits de proveedores | Múltiples RPCs, rotación |
| MongoDB Writes | ~10k writes/sec | Sharding (futuro) |
| Redis Pub/Sub | ~100k msgs/sec | Suficiente para MVP |
| WebSocket Connections | ~10k por instancia | Escalar horizontalmente |
Próximos Pasos
Ahora que entiendes la arquitectura general, puedes profundizar en:
- Microservices: Detalles de cada servicio
- Flujos de negocio: Cómo se ejecutan operaciones completas
- Sistema de seguridad: Capas de protección
- Deployment: Cómo se despliega todo esto
Nota para Desarrolladores
Este diagrama es tu mapa. Imprímelo, ponlo en la pared. Cuando tengas un bug:
- Identifica qué servicio está involucrado
- Mira cómo se comunica con otros
- Revisa los logs de ese servicio específico
- Traza el flujo de datos
La arquitectura no es accidental, cada decisión tiene su razón de ser.