Make retries deliberate
A timeout can leave the caller unsure whether a write committed. Retrying a non-idempotent insert may create a duplicate even though the first request succeeded. Prefer an upsert or a unique constraint when the data model supports that behavior.
For multi-step changes, use a transaction if the database operation supports it so the related updates are committed together or rolled back together. Keep each statement's intent narrow and bind values rather than composing SQL from untrusted text.
Confirm the stored outcome
Before retrying after a connection or workflow error, query by a stable identifier and inspect the current row. Do not infer that a timeout means nothing was written; distinguish a failed request from an unknown outcome.
Record the operation key and returned change information in run history where appropriate. For external side effects coupled to a write, use an outbox or explicit status transition so retries do not silently repeat notifications or payments.