Un flujo de pedido abarca pagos, inventario y envíos, cada uno con su propia base de datos. ¿Cómo mantienes todo consistente?

Renuncias a una única transacción distribuida y usas una saga: una secuencia de transacciones locales donde cada paso publica un evento que dispara el siguiente, y cada paso tiene una acción compensatoria para deshacerlo. La consistencia pasa a ser eventual, así que el trabajo de diseño es decidir qué compensar, qué reintentar y qué escalar a una persona. Modela el flujo de forma explícita, coreografiado con eventos o coordinado por un orquestador.

Un commit en dos fases entre tres servicios y tres bases de datos significa mantener bloqueos a través de la red y un coordinador que puede bloquearlo todo si muere, así que no lo haría. En su lugar el flujo se convierte en una saga. Cada servicio hace su transacción local y emite un evento, y cada paso tiene una compensación definida: si envíos no puede asignar, liberamos la reserva de inventario y reembolsamos o anulamos el pago. Lo importante es que la compensación es una acción de negocio, no un rollback; un reembolso deja un registro visible y eso es correcto. Para cualquier cosa con más de unos tres pasos uso un orquestador en vez de coreografía pura, porque con coreografía el flujo real no vive en ningún sitio y nadie puede responder dónde se ha quedado atascado un pedido. Un orquestador me da una sola máquina de estados, timeouts por paso y un estado consultable. Cada paso es idempotente y se reintenta con backoff, y todo lo que agota los reintentos aterriza en una cola de operaciones con el id del pedido, porque algunos fallos necesitan de verdad a una persona.