Cooking the Same Order Twice Shouldn't Double the Bill

Opening Scene

A ticket printer jams and spits out the same order twice. A less careful kitchen cooks both, and table six ends up with two identical entrees and a bill for two. A well-run kitchen has a habit that prevents this automatically: every ticket carries an order number, and the kitchen simply won’t fire a dish against a number it’s already completed, no matter how many times the same ticket comes through.

That habit — making a repeated action produce the same result as doing it once — is called idempotency, and it’s one of the quiet properties that separates a pipeline you can trust from one you have to babysit.

In Plain English

A process is idempotent if running it multiple times has the same effect as running it once. For a data pipeline, that means: if a job fails halfway through and gets automatically retried, or if someone accidentally runs it twice, the result should still be correct — no duplicated rows, no double-counted totals, no corrupted state. It sounds like a small technical detail. In practice, it’s the difference between a pipeline failure being a non-event and a pipeline failure requiring someone to manually clean up a mess at 2am.

The Old Way

Traditionally, idempotency was something a pipeline had, or didn’t, entirely depending on how carefully the engineer who wrote it thought about failure in advance. A naive pipeline simply appends new rows every time it runs — the kitchen equivalent of cooking whatever ticket comes through without ever checking the order number. That works fine until a retry happens, at which point the same batch of data gets loaded twice, and now every downstream report is quietly wrong until someone notices and manually deletes the duplicates.

Building idempotency in required deliberate design: using unique keys to detect and skip already-processed records, structuring loads so that re-running a batch overwrites rather than appends, checkpointing progress so a failed job resumes instead of restarting from zero. Good engineers built this habit into everything, the same way a good kitchen makes checking the order number automatic, not a special step someone has to remember.

What’s Changing (and Why AI Is the Reason)

1. Retries happen far more often, automatically. As pipelines run more continuously and touch more sources, transient failures — a timeout, a brief network hiccup, an API rate limit — are common and are increasingly handled by automatic retries rather than a person noticing and re-running a job. A pipeline that isn’t idempotent turns routine, automatic retries into routine, automatic data corruption.
2. AI-assisted pipeline generation can bake this in from the start. When AI tools help draft a new pipeline’s logic, the pattern of using unique keys and safe re-run behavior can be included as a default template rather than something a rushed engineer skips under deadline pressure — the equivalent of a kitchen’s ticket-number habit being trained into every new hire from day one, not left to chance.
3. Agents retry more aggressively than people do. An AI agent orchestrating a pipeline, or reacting to a failure, will often retry automatically and immediately, with none of a human’s instinct to pause and check what actually happened first. Non-idempotent pipelines are far more exposed in a world where the thing hitting “retry” doesn’t get tired or cautious.

The Metaphor, Fully Extended

Kitchen Element	Idempotency Concept
A ticket printer jamming and duplicating an order	A pipeline job being retried after a failure
Checking the order number before firing a dish	Checking a unique key before processing a record
Cooking the same ticket twice by mistake	A non-idempotent pipeline creating duplicate data
A kitchen that automatically ignores a repeated ticket number	A pipeline designed to safely no-op on already-processed data
Overwriting a mis-fired dish instead of adding another to the bill	A load pattern that overwrites rather than appends on rerun
A checklist trained into every new line cook	Idempotent patterns built into pipeline templates by default
An automatic ticket system that retries without a person watching	An AI agent retrying a failed pipeline step automatically

Quick Recap

• Idempotency means running a process multiple times has the same result as running it once — critical for safely handling retries.
• Non-idempotent pipelines silently duplicate or corrupt data whenever a retry happens, which used to be rare and is now routine.
• Building idempotency in requires deliberate design: unique keys, overwrite-safe loads, and checkpointed progress.
• AI-assisted pipeline generation can build this in as a default habit, and AI agents retrying failed steps make the absence of idempotency more exposed, not less.
• A quick way to catch a non-idempotent pipeline is simple: deliberately run it twice before it goes anywhere near production.

Where This Fits in the Series

Articles 1 through 5 walked the whole ETL/ELT journey and the two philosophies for running it. This article starts a run of pieces on what actually makes a pipeline trustworthy day to day. Article 7 looks at another everyday reliability question: when a pipeline should reload everything versus just what’s changed.