idempotency

SCD2 separates people who have run pipelines from people who have read about them. The whole answer hinges on one atomic MERGE that closes the old row and opens the new one, and stays correct when the job retries.

Pipelines fail and retry; the real question is whether a retry corrupts your data. The signal is idempotent writes (not 'exactly-once delivery') plus watermarks for late data. Here is how to make re-runs safe without double-counting.

A backfill that double-counts or takes down the live pipeline is worse than the original bug. The signal is idempotent partition-scoped rewrites, isolating backfill compute from live runs, and validating before swapping.

A celebrity posts and 50M followers need a notification. The hard parts are not sending one message, they are fan-out strategy, deduplication, channel routing, and not flooding users. Here is the architecture that handles both the long tail and the viral spike.

In payments, a duplicate charge or a lost credit is not a bug, it is a financial incident. The design hinges on idempotency keys, double-entry bookkeeping, and an append-only ledger that can be audited and reconciled. Here is how money systems stay correct.

Background jobs fail, retry, and get redelivered. If a job sends an email or charges a card, running it twice is a real problem. The design is at-least-once delivery plus idempotent handlers, visibility timeouts, and dead-letter queues. Here is how to make jobs safe.

Anyone can wire tasks into a DAG. The signal is the patterns that keep it correct under retries and backfills: idempotency, data-aware triggering, and the asset model. Here is what separates a flaky pipeline from a trustworthy one.