El asiento que se elige en dos despliegues

Una empresa de ómnibus de larga distancia vende 3.100 pasajes por día. Hace tres años el sistema era uno solo. Alguien propuso separarlo por responsabilidades y quedó partido en cuatro: venta de pasajes, mapa de asientos, equipaje y cobros. Cada uno con su base de datos.

Los cuatro últimos cambios de producto tocaron venta y asientos al mismo tiempo: butaca cama, asiento contiguo para el acompañante, bloqueo de la fila de emergencia y descuento por asiento de pasillo. Ninguno tocó sólo uno. Cada uno costó dos pull requests, dos despliegues coordinados y una tarde de alguien revisando cuál de los dos había quedado atrás.

Equipaje guarda su propia copia del viaje: origen, destino y horario. Cuando la empresa reprograma una salida por corte de ruta, la copia queda vieja hasta la próxima sincronización, y el mostrador de la terminal despacha bultos contra un horario que ya no existe.

Cobros es otra cosa. El cobro con tarjeta lo audita la marca de la tarjeta, y la auditoría pide poder mostrar qué pieza tocó el dato del cobro y cuándo. Esa frontera no la eligió el equipo.

El equipo son tres personas y su capacidad real es de 6 unidades operativas. Hoy el sistema usa 9. No es una opinión: es la cantidad de piezas que hay que actualizar, monitorear y respaldar cada semana.

Rearmá el sistema para que lo que siempre cambia junto viva junto, para que el pasaje tenga un solo dueño, y para que el dato del cobro se siga alcanzando sólo por el suyo. Vas a tener que sacar piezas, no agregarlas.