Diseñar un sistema escalable de reserva de entradas para conciertos

# Plan de Diseño del Sistema Escalable de Reservas de Entradas para Conciertos ## 1. Supuestos - Región única en la nube (p. ej., AWS us-east-1) con 3 Zonas de Disponibilidad (AZ); se prefieren servicios administrados. - El catálogo (eventos, recintos, mapas de asientos) es de lectura intensiva y cambia con poca frecuencia. - Las reservas son la ruta crítica; los pagos se realizan fuera de la ruta crítica a través de devoluciones de llamada asíncronas. - "Nunca vender de más" es un invariante estricto; se prefiere una indisponibilidad breve a la doble venta. - Un proveedor de pagos externo (p. ej., Stripe/Adyen) maneja el alcance PCI; solo almacenamos tokens. - Tamaño promedio de evento 30k asientos; el pico dura minutos a ~1 hora. ## 2. Arquitectura de Alto Nivel Clientes (web/móvil) → CDN (CloudFront) → API Gateway / Balanceador de Carga L7 → Autenticación de borde (JWT) → Microservicios sin estado en Kubernetes (EKS) a través de 3 AZs. Servicios principales: - **Servicio de Identidad**: registro, inicio de sesión, emisión de JWT, MFA. - **Servicio de Catálogo**: metadatos de eventos, recintos, mapas de asientos; optimizado para lectura. - **Servicio de Inventario/Asientos**: estado de asientos autoritativo, retenciones, reservas; el ancla de consistencia. - **Servicio de Reservas**: orquesta la retención → pago → intención de pago. - **Servicio de Pagos**: se integra con el proveedor, procesa devoluciones de llamada de webhook de forma idempotente. - **Servicio de Entradas**: emite entradas digitales firmadas (JWT/QR) tras el éxito del pago. - **Servicio de Notificaciones**: correo electrónico/push (SES/SNS). - **Servicio de Sala de Espera / Cola Virtual**: limita la entrada durante los picos de venta. - **Worker de Expiración**: libera retenciones no pagadas después de 10 minutos. - **Servicio de Administración/Venta**: configuración de eventos, carga de mapas de asientos, programación de ventas. Transversales: Kafka (MSK) para eventos, Redis (ElastiCache, modo clúster) para estado en caliente y bloqueos, PostgreSQL (Aurora Multi-AZ) para datos transaccionales, DynamoDB para claves de idempotencia y almacenamiento de entradas, S3 para JSON/imágenes de mapas de asientos, OpenSearch para búsqueda de eventos. ## 3. Almacenes de Datos - **Aurora PostgreSQL (Multi-AZ, 1 escritor + 2 lectores)**: eventos, usuarios, reservas, pagos, entradas (sistema de registro). Copia de seguridad continua; PITR. - **Clúster Redis (Multi-AZ, con réplicas)**: estado de retención por asiento, caché de mapa de bits de asientos por evento, límites de tasa, tokens de sala de espera. Se utiliza para CAS rápido en retenciones. - **DynamoDB**: claves de idempotencia de pago, deduplicación de webhooks, búsqueda de entradas emitidas (baja latencia, multi-AZ por defecto). - **Kafka (MSK)**: eventos de dominio (`SeatHeld`, `ReservationCreated`, `PaymentSucceeded`, `PaymentFailed`, `ReservationExpired`, `TicketIssued`). Factor de replicación 3 entre AZs. - **S3**: artefactos estáticos de mapas de asientos, PDFs de entradas. - **CDN**: almacena en caché listados de eventos, esqueleto de mapa de asientos (no disponibilidad en vivo). - **OpenSearch**: búsqueda/filtrado de eventos. ## 4. Modelo de Datos Principal **eventos**(event_id PK, venue_id, name, onsale_at, status, version). **asientos**(seat_id PK, event_id, section, row, number, price_tier, status ENUM[available, held, reserved, sold], hold_id NULL, version BIGINT). Índice compuesto (event_id, status). Versionado a nivel de fila para bloqueo optimista. **reservas**(reservation_id PK, user_id, event_id, seat_ids[], state ENUM[pending_payment, confirmed, expired, cancelled], created_at, expires_at, payment_intent_id, idempotency_key UNIQUE). **pagos**(payment_id PK, reservation_id, provider_ref UNIQUE, status, amount, currency, received_at). Restricción única en provider_ref para deduplicación al menos una vez. **entradas**(ticket_id PK, reservation_id, seat_id, qr_payload, issued_at, signature). **outbox**(id, aggregate, payload, published_at) para patrón outbox transaccional → Kafka. Claves de Redis: - `event:{id}:seat:{seat_id}` → estado + propietario de la retención + TTL 600s. - `event:{id}:availability` → bitmap/HLL para recuentos rápidos. - `hold:{reservation_id}` → lista de asientos, TTL 600s. ## 5. APIs Principales (REST + encabezados de idempotencia) - `GET /events?filters` → lista paginada (en caché por CDN, TTL de 30s). - `GET /events/{id}` → detalles del evento. - `GET /events/{id}/seatmap` → diseño estático (caché larga). - `GET /events/{id}/availability` → disponibilidad general (secciones); caché de 1–5s. - `GET /events/{id}/seats?section=A` → estado detallado de asientos (caché corta o en vivo). - `POST /reservations` (Idempotency-Key) → `{event_id, seat_ids[]}` → crea retención de 10 minutos. - `GET /reservations/{id}` → estado, expires_at. - `DELETE /reservations/{id}` → el usuario cancela, libera asientos. - `POST /reservations/{id}/checkout` → crea intención de pago en el proveedor, devuelve clave secreta del cliente. - `POST /webhooks/payments` → devolución de llamada del proveedor (firmada, idempotente). - `GET /tickets/{id}` → entrada digital firmada. - Administración: `POST /events`, `POST /events/{id}/seats:bulk`, `POST /events/{id}/onsale`. ## 6. Flujos de Solicitud ### Navegación Cliente → CDN (acierto para catálogo/mapa de asientos) → en caso de fallo, API → Servicio de Catálogo → Lector de Aurora / OpenSearch. Los recuentos de disponibilidad se sirven desde Redis con 1–5s de desactualización; los estados de asientos individuales se extraen en vivo para la sección que el usuario está viendo. ### Reserva (retención) 1. El cliente envía `POST /reservations` con Idempotency-Key y asientos objetivo. 2. API Gateway verifica el token de la sala de espera; limita la tasa por usuario/IP. 3. El Servicio de Reservas valida el estado del evento y los IDs de los asientos. 4. **Adquirir retenciones atómicamente** a través del script Lua de Redis: para cada clave de asiento, `SETNX` con hold_id y TTL 600s; si algún asiento falla, revierte los exitosos y devuelve 409 con los asientos en conflicto. 5. Persistir la fila de reserva en Aurora en estado `pending_payment` (transacción única con evento outbox). Utilizar bloqueo optimista en los asientos: `UPDATE seats SET status='held', hold_id=?, version=version+1 WHERE seat_id=? AND status='available'`. Aurora es la verdad duradera; Redis es el guardián rápido. Ambos deben estar de acuerdo. 6. Devolver la reserva con `expires_at`. p95 < 800 ms. ### Pago 1. El cliente llama a `POST /reservations/{id}/checkout`; el Servicio de Pagos crea un PaymentIntent en el proveedor, almacena `provider_ref` indexado por reservation_id (idempotente). 2. El cliente completa el pago a través del SDK del proveedor directamente (nos mantenemos fuera del alcance PCI). 3. El proveedor envía webhook → `POST /webhooks/payments`. 4. Manejador de Webhook: verificar firma → insertar/actualizar en `pagos` usando `provider_ref` UNIQUE (deduplicación). Usar escritura condicional de DynamoDB en event_id para idempotencia adicional. 5. En `succeeded`: actualización transaccional — reserva→`confirmed`, asientos→`sold`, escribir `tickets`, añadir evento outbox `TicketIssued`. Seguridad contra desorden: el manejador compara las marcas de tiempo de los eventos e ignora las transiciones obsoletas (máquina de estados: pending → confirmed/failed/expired, los estados terminales absorben duplicados tardíos). 6. El Servicio de Entradas consume `TicketIssued`, genera QR/PDF firmado, almacena en S3 + DynamoDB; el Servicio de Notificaciones envía correo electrónico al usuario. ### Expiración - Principal: el TTL de Redis expira la clave `hold:*` → la notificación de keyspace activa el worker de expiración; el worker ejecuta la transacción de Aurora liberando asientos solo si la reserva sigue `pending_payment` (CAS en el estado). - Respaldo: trabajo programado cada 30s escanea `reservas WHERE state='pending_payment' AND expires_at < now() - 30s` y libera. Devolución de llamada tardía que llega después de la expiración: si el asiento ya se revendió, marcar el pago como `refund_required` y activar el reembolso automático; si el asiento sigue libre, opcionalmente reconfirmar — pero la política predeterminada es el reembolso, porque no podemos volver a retener un asiento posiblemente revendido. El retraso de 5 minutos del proveedor de pagos está dentro de la ventana de retención de 10 minutos, por lo que el caso normal no tiene conflicto. ## 7. Prevención de Venta Excesiva (Consistencia) - El asiento es un recurso único y poseído: cada transición de estado utiliza **concurrencia optimista** en Aurora (`WHERE status=expected_status AND version=expected_version`). - Redis SETNX proporciona rechazo rápido de primera línea a 8k RPS sin sobrecargar la base de datos; la actualización de fila de Aurora es la segunda línea y la verdad legal. - Todas las escrituras del lado del pago son idempotentes a través de la unicidad de `provider_ref` + tabla de deduplicación de DynamoDB. - El patrón Outbox garantiza que los eventos de dominio se publiquen exactamente una vez en Kafka en relación con los commits de la base de datos. - Fuerte consistencia dentro de una sola fila de asiento; la consistencia eventual es aceptable solo para los recuentos de disponibilidad agregados que se muestran en las vistas de navegación. ## 8. Estrategia de Escalado para Picos - **Sala de espera virtual**: cuando `concurrent_users > threshold`, los nuevos usuarios obtienen un token de cola; solo se admiten N tokens/segundo a los puntos finales de reserva. Mantiene el sistema a una capacidad conocida (p. ej., admitir 10k/segundo para absorber 8k intentos de reserva/segundo). - **Escalado automático horizontal** (HPA en EKS) en métricas de CPU y RPS personalizadas; precalentar pods 15 minutos antes de las ventas anunciadas. - **Particionamiento de eventos calientes**: particionar claves de Redis por `event_id` para que un mega-evento único aterrice en un shard dedicado; se pueden preaprovisionar shards para ventas conocidas. - **Escalado de lectura**: réplicas de lectura de Aurora + Redis para disponibilidad + CDN para datos estáticos del mapa de asientos. - **Contrapresión**: cuotas de solicitud de API Gateway por usuario; 429 con Retry-After. - **Abanico asíncrono**: Kafka desacopla la generación de entradas, el correo electrónico y la analítica de la ruta crítica. - **Agrupación de conexiones**: RDS Proxy / PgBouncer para evitar tormentas de conexiones de Aurora. - **Defensa contra bots**: WAF, CAPTCHA en `POST /reservations` durante las ventas, huella digital del dispositivo. ## 9. Fiabilidad y Recuperación ante Desastres - Multi-AZ para cada componente con estado (Aurora, Redis con réplicas + conmutación por error automática, MSK RF=3, DynamoDB). - Aurora: copia de seguridad continua a S3, PITR a cualquier segundo dentro de la retención → RPO ≤ 1 min cumplido; conmutación por error ~30–60s → RTO ≤ 15 min cumplido. - Redis: Multi-AZ con conmutación por error automática; los datos se pueden reconstruir desde Aurora (las retenciones se pueden reconstruir en un inicio en frío desde `reservas WHERE state='pending_payment'`). - Kafka: almacenamiento por niveles, RF=3, min ISR=2. - Ejecución de DR: réplica de base de datos global de Aurora entre regiones (RPO ~ segundos) para recuperación ante fallos en toda la región; procedimiento de promoción documentado. - Simulacros de caos: apagón de AZ, eliminación del primario de Redis, simulación de interrupción del proveedor de pagos trimestralmente. - Comprobaciones de estado a nivel de ALB; disyuntores (similares a Resilience4j) entre servicios y hacia el proveedor de pagos. - Degradación elegante: si Redis no está disponible, recurrir a la ruta solo de base de datos con límite de tasa más estricto; si el proveedor de pagos está caído, poner en cola los pagos y notificar al usuario. ## 10. Monitorización y Alertas - **Métricas (Prometheus + CloudWatch)**: RPS, latencia p50/p95/p99 por punto final, tasa de éxito de reservas, tasa de conflicto de adquisición de retenciones, retraso del webhook de pago, retraso del worker de expiración, retraso de la réplica de Aurora, CPU/memoria/evicciones de Redis, retraso del consumidor de Kafka. - **SLOs**: disponibilidad del 99.95% en la ventana de venta; navegación p95 < 300 ms; reserva p95 < 800 ms; alertas de quema de presupuesto de error. - **Trazado**: OpenTelemetry de extremo a extremo (cliente → API → servicio → DB). - **Registros**: JSON estructurado a CloudWatch/Elastic; IDs de correlación. - **Paneles de control de negocio**: retenciones/seg, conversión (retención→pago), contador de venta excesiva (debe ser 0 — alerta ante cualquier valor no cero). - **Alertas**: violación de venta excesiva=0 (P0), cola de webhooks > 1 min, reserva p95 > 800 ms durante 5 min, conmutación por error de Aurora, conmutación por error de Redis, caída de la tasa de éxito de pagos > 2σ. ## 11. Compromisos y Alternativas Clave - **Redis como autoridad de retención vs. solo base de datos**: el enfoque de base de datos puro es más simple y más fuerte, pero no pudo mantener 8k RPS en puntos calientes de fila única; Redis en el front absorbe el pico, la actualización de fila de Aurora garantiza la corrección. - **Bloqueos pesimistas (SELECT FOR UPDATE)**: considerado; rechazado porque la contención de bloqueos en secciones populares reduciría drásticamente el rendimiento. El bloqueo optimista con reintentos escala mejor. - **Asientos reservados vs. contador de admisión general**: el diseño anterior es por asiento. Para admisión general, se utiliza un contador único que decrementa (`DECR` en Redis con un mínimo de 0, reflejado en la base de datos) en su lugar. - **Región única vs. región activa-activa**: la restricción dice una región. Activa-activa complicaría "nunca vender de más" (se necesita consenso entre regiones). Usamos réplica de lectura entre regiones solo para DR. - **Kafka vs. SQS**: Kafka elegido por su registro de eventos ordenado y reproducible (ayuda con el procesamiento de pagos desordenados y la reconstrucción del estado). - **Pago síncrono vs. solo webhook**: se eligió solo webhook para mantener la ligereza PCI y tolerar la latencia del proveedor; los retrasos de webhook de hasta 5 minutos aún caben dentro de la retención de 10 minutos. - **Sala de espera vs. escalado automático puro**: el escalado automático por sí solo no puede proteger los almacenes con estado posteriores; la cola proporciona una forma de carga determinista y una mejor experiencia de usuario que los 503 masivos. - **Emisión de entradas síncrona vs. asíncrona**: asíncrona a través de Kafka mantiene el manejador de devolución de llamada de pago rápido y resiliente; el usuario ve la entrada en segundos a través de push/actualización. Este diseño cumple con los SLOs declarados, previene la venta excesiva a través de concurrencia optimista en capas, absorbe los picos de venta a través de la cola virtual + retenciones con front de Redis, y satisface los objetivos de RPO/RTO a través de tiendas administradas Multi-AZ con PITR y conmutación por error ensayada.

## Diseño del Sistema: Sistema Escalable de Reserva de Entradas para Conciertos ### 1. Servicios Principales y Almacenes de Datos **Servicios:** * **API Gateway:** Punto de entrada para todas las solicitudes del cliente, maneja autenticación, limitación de velocidad y enrutamiento de solicitudes. * **Servicio de Usuarios:** Gestiona el registro de usuarios, perfiles y autenticación. * **Servicio de Eventos:** Gestiona detalles de eventos, horarios y contenido estático. * **Servicio de Asientos:** Gestiona el inventario de asientos, la disponibilidad y los datos del mapa de asientos para los eventos. * **Servicio de Reservas:** Maneja la lógica de reserva de asientos, gestiona los ciclos de vida de las reservas (pendiente, confirmada, caducada). * **Servicio de Pagos (Interno):** Orquesta las interacciones con proveedores de pago externos, procesa las devoluciones de llamada y gestiona los registros de pago internos. * **Servicio de Notificaciones:** Envía entradas digitales, correos electrónicos de confirmación y otras notificaciones al usuario. * **Servicio de Colas (Kafka):** Comunicación asíncrona entre servicios, maneja eventos de alto rendimiento (por ejemplo, devoluciones de llamada de pago, caducidad de reservas). * **Servicio de Caché (Redis):** Acceso a datos de alta velocidad para disponibilidad de asientos, detalles de eventos y bloqueos distribuidos. * **Servicio de Trabajadores en Segundo Plano:** Procesa tareas asíncronas como caducidad de reservas, reintentos de devoluciones de llamada de pago y limpieza de datos. **Almacenes de Datos:** * **PostgreSQL (Base de Datos Relacional):** Almacén de datos principal para usuarios, eventos, asientos, reservas y pagos. Elegido por sus sólidas propiedades ACID, cruciales para prevenir la sobreventa. * *Despliegue:* Configuración multi-AZ, primario-réplica con replicación síncrona para tablas críticas (asientos, reservas) y asíncrona para otras. * **Redis (Almacén de Datos en Memoria):** Utilizado para: * Caché de disponibilidad de asientos y detalles de eventos. * Bloqueos distribuidos para reserva y confirmación de asientos. * Temporizadores temporales de caducidad de reservas (claves TTL). * **Kafka (Plataforma de Streaming Distribuido):** Para paso de mensajes asíncrono y confiable y event sourcing. * **Almacenamiento de Objetos (por ejemplo, S3):** Almacena activos estáticos como imágenes de eventos, fotos de artistas y potencialmente PDFs de entradas digitales. ### 2. APIs Principales **Servicio de Usuarios:** * `POST /users/register`: Registrar un nuevo usuario. * `POST /users/login`: Autenticar usuario. * `GET /users/{id}`: Recuperar perfil de usuario. **Servicio de Eventos:** * `GET /events`: Navegar por todos los eventos (paginado). * `GET /events/{id}`: Recuperar detalles de un evento específico. * `GET /events/{id}/seatmap`: Recuperar mapa de asientos y disponibilidad actual para un evento. **Servicio de Reservas:** * `POST /events/{id}/reserve`: Reservar asientos específicos para un evento. Entrada: `event_id`, `seat_ids`, `user_id`. Salida: `reservation_id`, `expires_at`. * `GET /reservations/{id}`: Recuperar detalles de la reserva. * `DELETE /reservations/{id}`: Cancelar una reserva pendiente. * `POST /reservations/{id}/confirm`: Confirmar una reserva después de un pago exitoso (API interna, activada por el Servicio de Pagos). **Servicio de Pagos:** * `POST /payments/initiate`: Iniciar pago para una reserva. Entrada: `reservation_id`, `amount`, `user_id`. Salida: URL de redirección del proveedor de pagos. * `POST /payments/callback`: Punto final de webhook para devoluciones de llamada del proveedor de pagos externo (interno). **Servicio de Entradas (parte del Servicio de Notificaciones/Reservas):** * `GET /tickets/{id}`: Recuperar una entrada digital. ### 3. Modelo de Datos para Asientos y Reservas **Tabla: `users`** * `user_id` (PK, UUID) * `username` (VARCHAR, UNIQUE) * `email` (VARCHAR, UNIQUE) * `password_hash` (VARCHAR) * `created_at` (TIMESTAMP) **Tabla: `events`** * `event_id` (PK, UUID) * `name` (VARCHAR) * `venue` (VARCHAR) * `date_time` (TIMESTAMP) * `total_seats` (INT) * `image_url` (VARCHAR) **Tabla: `seats`** * `seat_id` (PK, UUID) * `event_id` (FK a `events.event_id`) * `section` (VARCHAR) * `row_number` (VARCHAR) * `seat_number` (VARCHAR) * `price` (DECIMAL) * `status` (ENUM: 'available', 'reserved', 'sold') * `version` (INT, para bloqueo optimista) **Tabla: `reservations`** * `reservation_id` (PK, UUID) * `user_id` (FK a `users.user_id`) * `event_id` (FK a `events.event_id`) * `status` (ENUM: 'pending', 'confirmed', 'expired', 'cancelled') * `reserved_at` (TIMESTAMP) * `expires_at` (TIMESTAMP) * `payment_id` (FK a `payments.payment_id`, nullable) * `total_amount` (DECIMAL) * `created_at` (TIMESTAMP) * `updated_at` (TIMESTAMP) **Tabla: `reservation_seats` (Tabla de Unión)** * `reservation_id` (FK a `reservations.reservation_id`) * `seat_id` (FK a `seats.seat_id`) * (PK Compuesta: `reservation_id`, `seat_id`) **Tabla: `payments`** * `payment_id` (PK, UUID) * `reservation_id` (FK a `reservations.reservation_id`) * `user_id` (FK a `users.user_id`) * `amount` (DECIMAL) * `currency` (VARCHAR) * `provider_transaction_id` (VARCHAR, UNIQUE) * `status` (ENUM: 'initiated', 'pending', 'succeeded', 'failed', 'refunded') * `created_at` (TIMESTAMP) * `updated_at` (TIMESTAMP) ### 4. Flujo de Solicitudes **A. Navegar por Eventos y Ver Disponibilidad de Asientos:** 1. **Solicitud del Usuario:** El navegador/aplicación del usuario solicita `/events` o `/events/{id}/seatmap`. 2. **CDN:** Sirve activos estáticos (imágenes de eventos, JS/CSS) si están en caché. 3. **API Gateway:** Autentica al usuario, enruta la solicitud al Servicio de Eventos o al Servicio de Asientos. 4. **Servicio de Eventos:** Recupera los detalles del evento de PostgreSQL (o caché de Redis). 5. **Servicio de Asientos:** Recupera el mapa de asientos y la disponibilidad de la caché de Redis. Si no está en caché, consulta la tabla `seats` de PostgreSQL, actualiza la caché y devuelve los datos. 6. **Respuesta:** Datos devueltos al usuario. (Latencia P95 < 300 ms). **B. Reservar Asientos:** 1. **Solicitud del Usuario:** El usuario selecciona asientos y hace clic en 'Reservar', enviando `POST /events/{id}/reserve` con `event_id`, `seat_ids`, `user_id`. 2. **API Gateway:** Enruta al Servicio de Reservas. 3. **Servicio de Reservas:** * **Bloqueo Distribuido:** Adquiere un bloqueo distribuido en Redis para cada `seat_id` para evitar modificaciones concurrentes. (por ejemplo, `LOCK:seat:{seat_id}`). * **Verificación de Estado del Asiento:** Consulta la tabla `seats` (o caché de Redis) para verificar que los asientos seleccionados estén 'available'. * **Transacción:** Inicia una transacción de base de datos. * **Actualizar Asientos:** Actualiza el `status` de los asientos seleccionados a 'reserved' en la tabla `seats`. * **Crear Reserva:** Inserta un nuevo registro en la tabla `reservations` con `status='pending'`, `reserved_at` y `expires_at` (hora actual + 10 minutos). * **Vincular Asientos:** Inserta registros en `reservation_seats` para cada asiento reservado. * **Confirmar Transacción.** * **Establecer TTL de Redis:** Establece una clave de Redis (por ejemplo, `RESERVATION_EXPIRY:{reservation_id}`) con un TTL de 10 minutos. Esto actúa como un disparador de caducidad de ruta rápida. * **Liberar Bloqueos:** Libera los bloqueos distribuidos para los asientos. 4. **Respuesta:** Devuelve `reservation_id` y `expires_at` al usuario. (Latencia P95 < 800 ms excluyendo el pago). **C. Pagar Reserva:** 1. **Acción del Usuario:** El usuario inicia el pago de una reserva `pending`. 2. **Solicitud del Usuario:** El navegador/aplicación envía `POST /payments/initiate` con `reservation_id` al Servicio de Pagos. 3. **Servicio de Pagos (Interno):** * Crea un registro de `payment` con `status='initiated'`. * Llama a la API del Proveedor de Pagos externo (por ejemplo, Stripe, PayPal) con los detalles de la reserva y el monto. * Redirige al usuario a la página del Proveedor de Pagos. 4. **Proveedor de Pagos Externo:** Procesa el pago. 5. **Devolución de Llamada del Proveedor de Pagos:** Tras un pago exitoso/fallido, el proveedor externo envía una devolución de llamada asíncrona (webhook) `POST /payments/callback` al Servicio de Pagos. 6. **Servicio de Pagos (Interno) - Manejador de Devolución de Llamada:** * **Verificación de Idempotencia:** Utiliza `provider_transaction_id` para garantizar que la devolución de llamada se procese solo una vez. * Actualiza el estado del registro `payment` (`succeeded` o `failed`). * Publica un evento `PaymentConfirmed` o `PaymentFailed` en Kafka, incluyendo `reservation_id` y `payment_id`. 7. **Servicio de Reservas - Consumidor de Kafka:** * Consume el evento `PaymentConfirmed`. * **Bloqueo Distribuido:** Adquiere un bloqueo para `reservation_id`. * **Transacción:** Inicia una transacción de base de datos. * **Actualizar Reserva:** Actualiza la tabla `reservations`: `status='confirmed'`, vincula `payment_id`. * **Actualizar Asientos:** Actualiza el `status` de los asientos asociados en la tabla `seats` a 'sold'. * **Confirmar Transacción.** * **Eliminar TTL de Redis:** Elimina la clave `RESERVATION_EXPIRY:{reservation_id}` de Redis. * **Liberar Bloqueo.** * Publica un evento `TicketIssued` en Kafka. 8. **Servicio de Notificaciones - Consumidor de Kafka:** Consume el evento `TicketIssued`, genera la entrada digital y envía un correo electrónico/notificación push al usuario. **D. Caducidad de Reservas:** 1. **Eventos Keyspace de Redis / Trabajador en Segundo Plano:** * **Ruta Rápida (TTL de Redis):** Cuando una clave `RESERVATION_EXPIRY:{reservation_id}` caduca en Redis, se activa un evento keyspace. Un microservicio dedicado o un trabajador en segundo plano consume este evento. * **Ruta Robusta (Escaneo de BD):** Un Servicio de Trabajadores en Segundo Plano escanea periódicamente (por ejemplo, cada 30 segundos) la tabla `reservations` en busca de registros donde `status='pending'` y `expires_at < hora_actual`. 2. **Lógica del Trabajador en Segundo Plano:** * Para cada reserva `pending` caducada: * **Bloqueo Distribuido:** Adquiere un bloqueo para `reservation_id`. * **Verificar Estado:** Verifica que la reserva siga siendo `pending` (para evitar caducar reservas ya pagadas debido a condiciones de carrera o eventos retrasados). * **Transacción:** Inicia una transacción de base de datos. * **Actualizar Reserva:** Actualiza la tabla `reservations`: `status='expired'`. * **Actualizar Asientos:** Actualiza el `status` de los asientos asociados en la tabla `seats` de nuevo a 'available'. * **Confirmar Transacción.** * **Liberar Bloqueo.** ### 5. Estrategia de Escalado para Picos de Tráfico * **Servicios sin Estado:** Todos los servicios de aplicaciones (Usuarios, Eventos, Asientos, Reservas, Pagos, Notificaciones) están diseñados para ser sin estado, lo que permite el escalado horizontal. * **Grupos de Escalado Automático (ASG):** Los servicios se implementan en ASG que agregan/eliminan automáticamente instancias basadas en métricas como la utilización de la CPU, la profundidad de la cola de solicitudes o métricas personalizadas (por ejemplo, reservas activas). * **Balanceadores de Carga:** Los Balanceadores de Carga de Aplicaciones (ALB) distribuyen el tráfico entrante entre las instancias saludables de cada servicio en múltiples Zonas de Disponibilidad. * **CDN:** La Red de Entrega de Contenido almacena en caché activos estáticos (imágenes de eventos, JS, CSS) para descargar tráfico de los servicios backend y reducir la latencia para los usuarios. * **Caché (Redis):** El uso extensivo de Redis para almacenar en caché datos accedidos con frecuencia (disponibilidad de asientos, detalles de eventos) reduce significativamente la carga de la base de datos, especialmente durante las vistas de navegación y mapas de asientos con muchas lecturas. * **Colas (Kafka):** Kafka actúa como un búfer, desacoplando servicios y absorbiendo picos de tráfico. Las operaciones asíncronas (devoluciones de llamada de pago, notificaciones, procesamiento de caducidad de reservas) se envían a Kafka, lo que permite a los servicios procesarlas a su propio ritmo sin bloquear las solicitudes del usuario. * **Réplicas de Lectura de Base de Datos:** Las instancias de PostgreSQL se configuran con múltiples réplicas de lectura. Los servicios con muchas lecturas (Servicio de Eventos, Servicio de Asientos para mapas de asientos) pueden dirigir sus consultas a estas réplicas, descargando la base de datos principal. * **Fragmentación de Base de Datos (Futuro Potencial):** Si una sola instancia de PostgreSQL se convierte en un cuello de botella para las escrituras, se podría considerar la fragmentación por `event_id` o `user_id`. Esto implicaría distribuir datos entre múltiples instancias de base de datos. * **Agrupación de Conexiones:** Gestión eficiente de las conexiones a la base de datos para minimizar la sobrecarga y maximizar el rendimiento. * **Limitación de Velocidad:** Implementada en la API Gateway para proteger los servicios backend del tráfico abusivo o de picos repentinos y abrumadores. ### 6. Enfoque de Fiabilidad y Recuperación ante Desastres * **Despliegue Multi-Zona de Disponibilidad (Multi-AZ):** Todos los servicios y almacenes de datos se implementan en al menos tres Zonas de Disponibilidad dentro de la región de la nube. Esto proporciona resiliencia contra fallos a nivel de AZ. * **Replicación y Conmutación por Error de Base de Datos:** * **PostgreSQL:** Configuración primario-réplica. Los datos críticos (asientos, reservas) utilizan replicación síncrona para garantizar un RPO < 1 minuto. Mecanismos de conmutación por error automatizados (por ejemplo, Patroni, conmutación por error de RDS administrada por la nube) promueven una réplica a primaria en caso de fallo de la primaria, logrando un RTO < 15 minutos. * **Redis:** Modo Sentinel o Cluster para alta disponibilidad, con datos replicados entre nodos en diferentes AZ. * **Durabilidad de Kafka:** Los brokers de Kafka se implementan en múltiples AZ con un factor de replicación > 1 (por ejemplo, 3) para garantizar la durabilidad de los mensajes y la disponibilidad incluso si falla una AZ o un broker. * **Copias de Seguridad Automatizadas:** Copias de seguridad regulares y automatizadas de PostgreSQL a almacenamiento de objetos con capacidades de recuperación a un punto en el tiempo. Instantáneas para Redis. * **Servicios sin Estado:** Los servicios están diseñados para ser sin estado, lo que significa que cualquier instancia puede ser reemplazada o reiniciada sin pérdida de datos, lo que contribuye a la alta disponibilidad. * **Circuit Breakers y Reintentos:** Implementados en la comunicación de servicio a servicio para prevenir fallos en cascada. Los servicios degradarán o reintentarán las solicitudes fallidas de forma elegante. * **Degradación Elegante:** Durante cargas extremas, las funciones no críticas (por ejemplo, recomendaciones personalizadas) podrían deshabilitarse temporalmente para priorizar la funcionalidad principal (reserva, pago). * **Objetivo de Punto de Recuperación (RPO) < 1 minuto:** Logrado mediante replicación síncrona de la base de datos para datos críticos y el registro de mensajes duradero de Kafka con configuraciones de replicación apropiadas. * **Objetivo de Tiempo de Recuperación (RTO) < 15 minutos:** Logrado mediante conmutación por error automatizada de la base de datos, escalado automático de los servicios de aplicaciones y instancias precalentadas o capacidades de aprovisionamiento rápido. ### 7. Elecciones de Consistencia que Previenen la Sobrevenda Prevenir la sobreventa es primordial y requiere una fuerte consistencia para las actualizaciones del estado de los asientos. * **Bloqueos Distribuidos (Redis):** Cuando un usuario intenta reservar asientos, el Servicio de Reservas adquiere un bloqueo distribuido para cada `seat_id` específico en Redis. Esto garantiza que solo un intento de reserva pueda modificar el estado de un asiento determinado en un momento dado. El bloqueo se mantiene durante la duración de la transacción de la base de datos que actualiza el estado del asiento y crea la reserva. * **Transacciones ACID (PostgreSQL):** Todas las actualizaciones del estado de `seats` y la creación/actualización de registros de `reservations` se realizan dentro de una única transacción ACID en PostgreSQL. Esto garantiza la atomicidad, consistencia, aislamiento y durabilidad. Si falla alguna parte de la transacción (por ejemplo, otro usuario ya reservó un asiento), toda la transacción se revierte, asegurando que no haya actualizaciones parciales y previniendo la sobreventa. * **Control de Concurrencia Optimista (Números de Versión):** Para la tabla `seats`, se puede agregar una columna `version`. Al actualizar el estado de un asiento, la consulta `UPDATE` incluye `WHERE version = <old_version>`. Si la versión no coincide, significa que otra transacción modificó el asiento, y la transacción actual puede ser reintentada o rechazada. Esto proporciona una capa adicional de protección contra condiciones de carrera, especialmente si los bloqueos distribuidos fallan o no se implementan perfectamente. * **Procesamiento Idempotente de Pagos:** Las devoluciones de llamada del proveedor de pagos son `al menos una vez` y pueden estar desordenadas. El Servicio de Pagos procesa estas devoluciones de llamada de forma idempotente, utilizando el `provider_transaction_id` para garantizar que un pago exitoso solo se aplique una vez a una reserva, previniendo confirmaciones dobles o actualizaciones de estado incorrectas. * **Lógica de Caducidad de Reservas:** El proceso de caducidad verifica explícitamente si una reserva sigue siendo `pending` antes de marcarla como `expired` y liberar los asientos. Esto evita una condición de carrera en la que un pago podría llegar justo cuando el proceso de caducidad está a punto de ejecutarse. ### 8. Monitorización y Alertas * **Recopilación de Métricas:** Utilizar Prometheus/Grafana o monitorización nativa de la nube (por ejemplo, CloudWatch, Stackdriver) para recopilar métricas de todos los servicios, bases de datos, cachés y colas. Métricas clave incluyen: * **Métricas del Sistema:** Utilización de CPU, uso de memoria, E/S de disco, E/S de red. * **Métricas de Aplicación:** Tasas de solicitud, tasas de error (5xx), latencia (p95, p99) para todos los puntos finales de la API, profundidades de cola, conexiones activas, recolección de basura. * **Métricas de Base de Datos:** Latencia de consulta, uso del pool de conexiones, tasas de transacciones, latencia de replicación, interbloqueos. * **Métricas de Caché:** Relación aciertos/fallos de caché, uso de memoria. * **Métricas de Kafka:** Latencia del productor/consumidor, tasas de mensajes, estado del broker. * **Registro Centralizado:** Agregar registros de todos los servicios en un sistema de registro centralizado (por ejemplo, pila ELK, Splunk, Datadog). Utilizar registro estructurado para un análisis y análisis más sencillos. * **Trazado Distribuido:** Implementar trazado distribuido (por ejemplo, OpenTelemetry, Jaeger) para visualizar flujos de solicitudes a través de múltiples servicios, identificar cuellos de botella y depurar interacciones complejas. * **Alertas:** Configurar alertas para umbrales críticos: * Altas tasas de error (por ejemplo, 5% de errores 5xx durante 5 minutos). * Alta latencia (por ejemplo, latencia de API p95 > 800 ms). * Caída del servicio o instancias no saludables. * Latencia de replicación de base de datos que excede los umbrales. * Retrocesos de cola. * Devoluciones de llamada de pago fallidas o fallos en la caducidad de reservas. * Agotamiento de recursos (CPU, memoria, disco). * **Paneles:** Crear paneles en tiempo real para visibilidad operativa, que muestren métricas clave y estado del servicio. ### 9. Compromisos Clave o Alternativas * **Elección de Base de Datos:** * **Alternativa:** Base de datos NoSQL (por ejemplo, Cassandra, DynamoDB) para una escalabilidad de escritura extrema. **Compromiso:** Si bien NoSQL puede manejar una escala masiva, lograr una fuerte consistencia para operaciones transaccionales complejas como las reservas de asientos (que implican múltiples actualizaciones y verificaciones) es significativamente más desafiante y a menudo requiere lógica a nivel de aplicación compleja. Las propiedades ACID de PostgreSQL simplifican la prevención de la sobreventa, y su escalabilidad se puede gestionar mediante réplicas de lectura y fragmentación. * **Mecanismo de Bloqueo:** * **Alternativa:** Bloqueos de fila a nivel de base de datos. **Compromiso:** Pueden generar una mayor contención y posibles interbloqueos en escenarios de alta concurrencia, lo que afecta el rendimiento. Los bloqueos distribuidos de Redis son generalmente más rápidos y descargan el mecanismo de bloqueo de la base de datos, pero requieren una implementación cuidadosa (por ejemplo, manejo de la caducidad del bloqueo, garantía de atomicidad de la adquisición/liberación del bloqueo). * **Caducidad de Reservas:** * **Alternativa:** Depender puramente de los eventos keyspace TTL de Redis. **Compromiso:** Si bien es rápido, la entrega de eventos keyspace de Redis no está garantizada (por ejemplo, si Redis se reinicia o se pierden eventos). El enfoque elegido combina el TTL de Redis para una ruta rápida con un trabajador robusto que escanea la base de datos para una consistencia eventual, asegurando que ninguna reserva quede permanentemente en `pending`. * **Manejo de Devoluciones de Llamada de Pago:** * **Alternativa:** Devolución de llamada síncrona del proveedor de pagos. **Compromiso:** Esto rara vez lo ofrecen los proveedores externos y requeriría que la plataforma sea altamente disponible y receptiva al proveedor de pagos, introduciendo un acoplamiento estrecho. El enfoque asíncrono, `al menos una vez`, a través de Kafka es estándar y más resistente, pero requiere procesamiento idempotente y manejo de mensajes desordenados. * **Microservicios vs. Monolito:** * **Alternativa:** Arquitectura monolítica. **Compromiso:** Más simple de desarrollar inicialmente, pero más difícil de escalar componentes individuales, desplegar de forma independiente y gestionar para equipos grandes. Los microservicios ofrecen mejor escalabilidad, aislamiento de fallos y diversidad tecnológica, pero introducen complejidad operativa (transacciones distribuidas, monitorización, despliegue). ### 10. Supuestos * **Autenticación de Usuario:** Los usuarios se autentican antes de realizar cualquier acción que requiera identidad (por ejemplo, reservar asientos, ver entradas). * **Cumplimiento PCI:** El proveedor de pagos externo maneja todos los requisitos de cumplimiento PCI DSS; el Servicio de Pagos interno solo orquesta y almacena datos de pago mínimos y no sensibles. * **Capacidad de la Región de la Nube:** La región de la nube elegida tiene suficiente capacidad de cómputo, red y almacenamiento para manejar las cargas pico especificadas. * **Latencia de Red:** La latencia de la red interna dentro de la región de la nube y entre las Zonas de Disponibilidad es lo suficientemente baja como para cumplir los objetivos de latencia. * **Seguridad:** Se implementan prácticas de seguridad estándar (por ejemplo, cifrado en tránsito y en reposo, validación de entrada, control de acceso, escaneo de vulnerabilidades) en todo el sistema, aunque no se detallan en este diseño. * **Fiabilidad del Proveedor de Pagos Externo:** Se asume que el proveedor de pagos externo es altamente disponible y fiable para procesar pagos y enviar devoluciones de llamada.