Senior · MongoDB with Go

Transactions and external side effects

Can a MongoDB transaction callback send a payment or email?

Try explaining this aloud before opening the answer. State your assumptions and trace a boundary case.

Reveal a strong answer
  1. Use a transaction only when an invariant spans documents and the deployment supports the required transaction behavior. Keep it short and use the session context consistently for every participating operation.

  2. Driver transaction helpers may rerun work under documented retry conditions. A callback must not assume it runs once. Remote payments, emails and broker publishes are outside the database atomic boundary.

  3. Persist an outbox or intent with the domain update, then perform external work through an idempotent protocol. Consider commit uncertainty, read/write concern and reconciliation. A transaction can coordinate database state but cannot roll back a delivered email.

Common trap

Putting an HTTP call inside a transaction does not make it transactional.

Try it

A transaction callback runs twice after a transient error. What breaks if it charges a card each time?

Worked solution

The remote charge can duplicate. Move the side effect behind a stable operation ID/outbox and reconcile with the provider. Unit tests should deliberately invoke the callback more than once, while integration tests verify actual database behavior.

Change the constraint

When might schema redesign into one atomic document be simpler than a cross-document transaction?

How did you do?

Self-assessment, not a compiler pass or interview score. Explain the reasoning unaided before marking understood.

Not marked. Progress stays on this browser, separate from course completion.

Primary references

Checked 2026-10-20. Use documentation for your pinned runtime, driver and tool version.