Para evitar la sobreventa de asientos cuando dos usuarios intentan reservar el último disponible al mismo tiempo, analizamos distintas arquitecturas:
| Arquitectura | Descripción | ¿Es adecuada? |
|---|---|---|
| Hexagonal (Ports & Adapters) | Separa la lógica de negocio de la infraestructura, pero no resuelve concurrencia por sí solo. | ❌ No |
| Microservicios | Escalable, pero no soluciona concurrencia a menos que se use un mecanismo de control adicional. | ⚠️ Depende |
| Basado en Eventos (Event-Driven) | Facilita coordinación de flujos, pero puede generar sobreventa si no se maneja correctamente. | ⚠️ Depende |
| CQRS | Separa lectura y escritura, ideal con Event Sourcing para manejar concurrencia. | ✅ Buena opción |
| Capas (N-Tier) | Organiza el código, pero no resuelve problemas de concurrencia. | ❌ No |
| Patrón Saga | Maneja transacciones distribuidas y evita inconsistencias en reservas. | ✅ Recomendado |
| API Gateway & BFF | Facilita la gestión de APIs, pero no resuelve concurrencia. | ❌ No |
Si la reserva de asientos es parte de un sistema más grande, Saga es ideal para manejar transacciones distribuidas. Si solo necesitas evitar sobreventa en un solo servicio, CQRS con Event Sourcing es una excelente opción.