Selección de arquitectura para un sistema de reservas con picos de demanda
Una aerolínea regional necesita un sistema de reservas. Requisitos: 2 000 reservas por minuto en horas pico, consistencia fuerte en la asignación de asientos (no vender dos veces el mismo asiento), disponibilidad 99.9%, y un equipo de 6 desarrolladores con experiencia en Java y SQL pero sin experiencia en sistemas distribuidos. El presupuesto permite una base de datos relacional gestionada con réplicas. Se propone un diseño de microservicios con Kafka, tres servicios y consistencia eventual para la asignación de asientos, argumentando que 'escala mejor'.
1. Evalúa la propuesta de microservicios con consistencia eventual frente a los requisitos y al equipo disponible.
Read the worked answer
La propuesta choca con el requisito de consistencia fuerte: con consistencia eventual, dos usuarios podrían reservar el mismo asiento y resolverse después, lo que en un sistema de reservas es un fallo de negocio inaceptable (sobreventa y reclamos). La asignación de asientos requiere una operación atómica y serializable, natural en una base relacional con transacciones y bloqueo o restricción única.
El argumento de escalabilidad es débil: 2 000 reservas/minuto (~33/s) es una carga moderada que una base relacional gestionada con réplicas y buen indexado absorbe sin problema. Los microservicios con Kafka añaden complejidad operativa (particiones, idempotencia, reintentos, observabilidad distribuida) que un equipo de 6 personas sin experiencia en sistemas distribuidos no puede sostener, elevando el riesgo de incidentes y la deuda operativa.
La opción adecuada es un monolito modular o pocos servicios sobre una base relacional con transacciones, escalado vertical y réplicas de lectura, reservando la mensajería para tareas no críticas (notificaciones, informes).
2. El equipo insiste en microservicios por presión de la dirección. ¿Qué condiciones mínimas deberían cumplirse antes de aceptar ese camino?
Read the worked answer
Aceptar solo con condiciones verificables:
- Mantener consistencia fuerte en el dominio crítico: el servicio de asientos debe usar una base transaccional con restricción única o bloqueo, no consistencia eventual. La mensajería no puede mediar la decisión de asignación.
- Capacitación y roles: al menos un responsable de plataforma con experiencia en sistemas distribuidos, formación en idempotencia, sagas y observabilidad, y tiempo dedicado en el plan.
- Infraestructura de observabilidad y despliegue: trazas distribuidas, métricas, alertas y CI/CD antes de dividir el sistema.
- Estrategia de migración incremental: empezar por un módulo de bajo riesgo (notificaciones), medir, y no dividir el núcleo transaccional hasta validar.
- Criterios de éxito y reversión: latencia, tasa de error, costo operativo y plan para volver atrás.
Si no se cumplen, la decisión correcta es documentar el riesgo y proponer el monolito modular como paso previo. Aceptar microservicios sin estas condiciones traslada un riesgo técnico no gestionado al negocio.