Postgres sigue ganando en sistemas distribuidos

Si estás construyendo workflows que mueven dinero, actualizan inventario, disparan emails o coordinan tareas entre varios servicios, ya sabes dónde se rompe todo: en la coordinación. Un paso se ejecuta, otro falla, el tercero queda a medias y luego tienes que reconstruir qué pasó con logs, colas, reintentos y scripts de compensación. El problema no suele ser la lógica de negocio. El problema es mantener el estado consistente cuando tu sistema ya no vive en un solo proceso.

Ahí es donde Postgres sigue siendo una pieza estratégica. No porque sea “la base de datos que ya conoces”, sino porque sus transacciones te dejan agrupar cambios relacionados en una sola unidad confiable. Si el workflow escribe en la misma base donde vive el estado, puedes hacer que el cambio de datos y el avance del proceso ocurran juntos. Eso reduce el número de piezas que pueden fallar y, sobre todo, reduce el número de lugares donde tienes que razonar sobre consistencia.

El problema real: coordinar estado en sistemas distribuidos

En una arquitectura distribuida típica, el estado de un workflow puede quedar repartido entre varios servicios: una API registra el pedido, otra cola envía el evento, un worker procesa el pago y un tercero actualiza el inventario. Cada frontera entre servicios agrega latencia, puntos de fallo y, casi siempre, incertidumbre. El resultado es que terminas programando alrededor de la inconsistencia en vez de programar la lógica del negocio.

Un ejemplo simple: recibes un pedido de 120 dólares, reservas inventario y luego intentas cobrar. Si el cobro falla después de haber reservado stock, necesitas compensar la reserva. Si el evento de compensación no llega, tu inventario queda mal. Si el worker se cae después de cobrar pero antes de marcar el pedido como pagado, podrías cobrar dos veces al reintentar. Nada de esto es raro; son escenarios normales cuando el estado está distribuido sin una estrategia clara de transacciones.

Postgres ayuda porque te permite mover la frontera de confiabilidad. En lugar de tratar cada paso como una conversación entre servicios separados, puedes guardar el estado del workflow y sus cambios en la misma transacción. Eso no elimina los fallos, pero sí te da una regla simple: o todo el cambio se confirma, o nada se escribe. Para muchos workflows, esa regla vale más que una pila de componentes “escalables” pero difíciles de operar.

Dónde se rompe la complejidad

Cuando separas demasiado el estado, aparecen patrones conocidos:

1. Duplicación de eventos por reintentos.
2. Estados intermedios visibles para otros servicios.
3. Compensaciones manuales o frágiles.
4. Debugging basado en correlacionar logs de varias herramientas.
5. Costos operativos altos por colas, brokers y orquestadores.

No es que estos patrones sean incorrectos. Es que muchas veces se usan antes de que realmente hagan falta. Si tu workflow cabe en una transacción de base de datos y una tabla de estado, probablemente no necesitas una orquesta completa para resolver un problema que Postgres ya sabe manejar bastante bien.

Por qué las transacciones de Postgres cambian el juego operativo

Las transacciones de Postgres te dan atomicidad, aislamiento y durabilidad en una sola operación lógica. Traducido a lenguaje de producto: puedes escribir varias filas relacionadas, validar reglas y avanzar el estado de un proceso sin dejar huellas parciales si algo falla. Eso tiene un impacto directo en workflows porque te permite diseñar pasos idempotentes, previsibles y fáciles de auditar.

La ventaja no está solo en “guardar datos”. Está en co-localizar el estado del workflow con los datos que ese workflow modifica. Si tu pedido, tu pago y tu estado de procesamiento viven en el mismo lugar, puedes usar una sola transacción para registrar el cambio y dejar el sistema listo para el siguiente paso. Menos saltos entre servicios significa menos coordinación externa y menos probabilidad de inconsistencias difíciles de reproducir.

Postgres también te da herramientas que encajan bien con procesos distribuidos: SELECT ... FOR UPDATE para bloquear filas durante una decisión crítica, UNIQUE para evitar duplicados, CHECK para validar estados, y SKIP LOCKED para repartir trabajo entre workers sin pisarse. No necesitas inventar un coordinador externo para cada caso si la base ya te ofrece primitivas sólidas.

Lo que realmente ganas en un workflow

Cuando el workflow vive cerca de sus datos, ganas cuatro cosas prácticas:

• Menos componentes que operar.
• Menos estados intermedios expuestos.
• Menos reintentos peligrosos.
• Más facilidad para auditar qué pasó y cuándo.

Eso no significa que Postgres resuelva todo. Significa que, para una clase enorme de problemas, te permite mantener la coordinación en un solo lugar confiable en vez de repartirla entre varios servicios que luego tienes que reconciliar.

Un ejemplo con pedidos y pagos

Imagina este flujo: creas un pedido, reservas inventario y dejas listo un trabajo pendiente para cobrar. Si todo eso ocurre dentro de una transacción, puedes asegurar que el pedido no quede “creado” sin su registro de siguiente paso. Si la aplicación cae antes del commit, no hay pedido a medias. Si el commit ocurre, el sistema sabe exactamente qué hacer después.

En cambio, si primero escribes el pedido, luego publicas un evento y después actualizas inventario, ya dependes de que cada paso externo funcione bien. El famoso patrón de outbox existe justamente para acercarte a esta confiabilidad. Y ese detalle dice mucho: cuando los equipos terminan reimplementando confiabilidad encima de una base de datos, normalmente es porque la base de datos sigue siendo el lugar natural donde debería vivir el estado.

Co-localizar el workflow con los datos reduce fallos

La idea central del artículo fuente es simple: si el estado del workflow está junto a los datos que modifica, el sistema se vuelve más fácil de razonar. No eliminas la distribución, pero sí reduces cuántas cosas tienen que coordinarse fuera de la base. Eso es una diferencia enorme en producción, porque cada servicio adicional agrega una nueva forma de fallar.

Piénsalo así: una arquitectura con cola, worker, orquestador y base de datos puede funcionar bien, pero cada capa añade su propio modelo de consistencia. Tienes que pensar en al menos cuatro cosas a la vez: si el mensaje se publicó, si el worker lo consumió, si la base confirmó el cambio y si el estado externo quedó sincronizado. Con Postgres, muchas de esas decisiones pueden colapsar en una sola transacción y una sola fuente de verdad.

Esto también mejora el debugging. Cuando el workflow y los datos están en la misma base, puedes consultar el estado actual, el historial y los intentos fallidos sin saltar entre sistemas. Si además guardas timestamps y estados explícitos, obtienes trazabilidad suficiente para responder preguntas como “¿por qué este pedido quedó pendiente?” sin depender solo de logs dispersos.

Qué cambia en la práctica

Supón que tienes un proceso de aprobación interna. Un usuario envía una solicitud, el sistema valida reglas, asigna un aprobador y deja la tarea lista. Si todo eso se registra en Postgres dentro de una transacción, puedes garantizar que la solicitud no quede en un estado imposible, como “aprobada” sin aprobador o “pendiente” sin referencia al siguiente paso.

Ahora mira la misma lógica con servicios separados. Un servicio crea la solicitud, otro notifica al aprobador y un tercero actualiza el estado cuando recibe respuesta. Si el segundo servicio falla, la solicitud existe pero nadie fue notificado. Si el tercero recibe dos eventos por reintento, puedes terminar con estados duplicados. El costo no es solo técnico; también es de soporte, porque alguien tendrá que revisar qué pasó.

Tabla comparativa: más piezas, más coordinación

La tabla no dice que una arquitectura distribuida sea mala. Dice que, si puedes resolver el problema con una transacción y una tabla de estado, probablemente estás comprando menos riesgo con menos complejidad.

Patrones que sí aprovechan Postgres sin forzar la arquitectura

Hay varias formas de usar Postgres como centro de gravedad de workflows sin caer en un diseño monolítico rígido. La clave es no confundir simplicidad con improvisación. Puedes tener una arquitectura limpia y seguir usando la base como fuente de verdad de la coordinación.

Un patrón útil es guardar una fila por workflow con un estado explícito: pending, processing, completed, failed. Cada transición ocurre dentro de una transacción y, si hace falta, se acompaña de una tabla de eventos o auditoría. Otro patrón es usar una tabla de jobs con SKIP LOCKED para que varios workers tomen tareas sin duplicarlas.

También puedes combinar una transacción con el patrón outbox. Primero escribes el cambio de negocio y el evento saliente en la misma transacción. Luego un proceso separado lee la outbox y publica a Kafka, SQS o RabbitMQ. Así mantienes consistencia entre la base y la intención de publicar eventos, sin depender de que ambos sistemas confirmen al mismo tiempo.

Tres patrones útiles

1. State machine en una tabla: ideal para procesos con estados claros y pocos pasos.
2. Job queue con SKIP LOCKED: útil para repartir trabajo entre varios workers sin colisiones.
3. Outbox pattern: sirve cuando necesitas integrar con otros sistemas sin perder consistencia.

Si quieres profundizar en las primitivas de bloqueo y aislamiento, la documentación oficial de Postgres es el mejor punto de partida: https://www.postgresql.org/docs/current/explicit-locking.html y https://www.postgresql.org/docs/current/sql-select.html. Si tu equipo usa transacciones en serio, conviene leerlas con ejemplos reales de tu dominio, no como teoría abstracta.

Cuándo no conviene meter todo en la base

No todo workflow debe vivir en Postgres. Si tienes millones de eventos por segundo, procesamiento de streaming o una topología donde cada paso necesita escalar de forma independiente, una arquitectura más distribuida puede tener sentido. También hay casos donde el dominio exige integración fuerte con sistemas externos que no puedes encapsular fácilmente.

Pero incluso ahí, Postgres puede seguir siendo el ancla del estado crítico. Puedes dejar que otros sistemas manejen la entrega o el cómputo pesado, mientras la base conserva el registro confiable de qué pasó, qué falta y cuál es el siguiente paso válido.

Cómo diseñar workflows confiables sin sobrediseñar

La forma más útil de pensar esto es simple: primero diseña el workflow alrededor de la consistencia, luego decide qué partes realmente necesitan salir de la base. No empieces por la cola, el broker o el orquestador. Empieza por el estado que no puedes permitirte perder.

Una secuencia práctica para equipos pequeños y medianos sería esta:

1. Define el estado del workflow en una tabla clara.
2. Identifica qué cambios deben ser atómicos.
3. Encapsula esos cambios en una sola transacción.
4. Agrega un worker o proceso externo solo cuando el paso siguiente no pueda correr dentro del mismo sistema.
5. Usa idempotencia en los pasos que pueden reintentarse.
6. Añade observabilidad con timestamps, estados y errores normalizados.

Este enfoque evita que construyas una arquitectura más grande de lo necesario. Además, te deja crecer por etapas. Puedes empezar con una sola API y una base de datos, y luego extraer componentes cuando el volumen o la complejidad realmente lo justifiquen.

Señales de que Postgres te alcanza

Hay señales bastante claras de que no necesitas complicarte todavía:

• Tu workflow tiene menos de 10 estados bien definidos.
• La mayoría de los cambios son escritura de filas, no cómputo pesado.
• El volumen de tareas por segundo todavía es manejable con una tabla de jobs.
• Tu principal dolor hoy es consistencia, no throughput extremo.

Si te ves reflejado en varias de esas señales, lo más probable es que Postgres te dé una mejor relación entre confiabilidad y costo operativo que una arquitectura distribuida más elaborada.

Tabla resumen

Postgres no ganó por moda. Sigue ganando porque resuelve una parte muy difícil de los sistemas distribuidos: mantener el estado coherente cuando todo lo demás puede fallar. Si tu workflow depende de que varios pasos ocurran en orden y sin duplicarse, la transacción sigue siendo una herramienta difícil de superar.

La lección práctica es esta: no subestimes lo que puedes simplificar si el estado del proceso vive junto a los datos. En muchos productos, esa decisión te ahorra semanas de trabajo de soporte más adelante, y te da una base mucho más clara para crecer sin convertir cada cambio en una mini operación distribuida.