resonate-external-system-of-record-pattern-python

To ensure idempotent writes to PostgreSQL from durable Python workflows, write to the external system of record first using an external idempotency key, and wrap all database I/O in deterministic ctx.run checkpoints to prevent duplicate executions on replay.

Durable workflows re-execute external database calls during replay when those interactions are not properly checkpointed. Wrapping I/O operations in deterministic ctx.run calls durably records results, ensuring external dependency usage via ctx.get_dependency is not re-executed on replay.

The best way to keep business state consistent is to make TigerBeetle the authoritative system of record with idempotent writes first, then treat secondary search indexes as compensatable or best-effort writes to avoid in-memory, non-durable reads.

Yes, you can use external message brokers as the system of record for Python workflow state by applying idempotency keys and deterministic ctx.run checkpointing. This ensures the broker remains the single source of truth for durable workflow interactions.

You should avoid in-memory state reads in durable Resonate workflows whenever business state consistency is required. Always perform explicit authoritative reads from the external system of record on replay to guarantee durable, accurate state synchronization.