skip to content

Why does submitting the same workload spec twice converge on one set of copies instead of adding more?

level: middleimportance: should knowfreq 52%

answer

  1. state, not a delta
  2. four means four, not plus four
  3. same name, same record
  4. same input, same document
  5. a generated name breaks it

basics

~10 s

Because the document is an absolute statement about a named workload, not an instruction. Four copies means there shall be four, so the second submission finds nothing to change and asks for nothing new.

solid answer

~40 s

Two properties make it converge. First, the values are **absolute**: `replicas: 4` says the end state is four copies, not "add four", so repeating it cannot compound. Second, the document carries a **stable identity** — the workload's name — so the second submission updates the same record rather than creating a second one. Together they mean that submitting N times has the effect of submitting once, which is what makes re-submission a safe recovery action after a failed or half-finished change. It stops being true the moment a value is generated at submission time: a workload name built from the clock produces a new record every time, and then repetition really does accumulate.

code

pseudocode · 11 lines
pseudocode
# absolute: a statement about the end state
declare workload "orders-api" { replicas = 4 }
# submit twice -> still 4, because 4 is not "plus 4"

# incremental: an instruction, applied each time it is issued
add_copies("orders-api", 2)
# issue twice from 4 -> 8

# the property depends on a stable identity
declare workload "orders-api-" + now()  { replicas = 4 }
# submit twice -> two workloads, 8 copies

go deeper

for a junior

Hold on to the reading: four copies means there shall be four, not add four. That is why submitting the same document again is a safe thing to do after an unclear outcome.

for a middle

Give both halves of the mechanism — absolute values and a stable identity — and show that either one missing breaks it, with the generated-name case as the example.

for a senior

Demonstrate the operational payoff and its limits: retries and duplicate pipeline runs need no did-it-already-happen check, but repetition neither restarts copies nor creates capacity.

for a principal

The lever is authoring discipline across teams. Templating that injects clock values or random suffixes silently converts a safe-to-repeat estate into one where nobody dares re-submit.

## A count is a quantity, not a verb The whole behaviour follows from how the numbers in a spec are meant to be read. `replicas: 4` is a claim about the finished picture — *there shall be four copies of this workload* — and a claim does not become a different claim by being repeated. Submitting the document a second time restates the same thing, the platform compares it with what exists, finds no difference, and there is nothing to do. An instruction behaves in the opposite way. "Add two copies" is meaningful only relative to a starting point, so issuing it twice from four copies leaves eight. That is the distinction to name in an interview: **a declared value is state, an instruction is a delta**, and only one of those two is safe to repeat. | | Absolute declaration | Incremental instruction | |---|---|---| | reads as | there shall be four copies | add two copies | | depends on the current state | no | yes | | submitted twice | still four copies | four extra copies | | safe after an unclear outcome | yes, just submit again | no, you must first find out what happened | | carries its own meaning in isolation | yes | only with the starting point attached | ## Identity is what makes the second submission an update Absolute values alone are not enough. If each submission created a brand-new record, two documents each declaring four copies would produce eight copies, however absolute each one was. The second property is that the document names the workload, and that name is the **identity of the record**. The platform matches the incoming document to the existing one by that identity and updates it in place; there is only ever one stored object for that workload, holding the latest statement of intent. This is also why the platform can tell a change from a repetition at all. Field by field, the incoming document either matches the stored one or does not, and the difference — possibly empty — is the entire content of "what was asked for this time". ## What re-submission is not A common overcorrection is to treat an idempotent submission as harmless in every sense, including as a way to give a workload a nudge. 1. **It is not a restart.** If nothing in the document differs, nothing about the running copies changes. The copies are not recreated, not moved and not reloaded. 2. **It does not repair a copy.** Re-submitting an unchanged spec makes no statement about a failing copy; whatever was going to happen to it happens anyway. 3. **It does not force a re-read of anything the spec points at.** The spec's own values are what is compared, not whatever they refer to. 4. **It is not a guarantee of success.** A perfectly idempotent document that asks for more capacity than exists is still unsatisfiable, and repeating it does not create room. ## Where the property breaks Idempotence is a property of the *document*, and it is easy to author it away: - **A generated identity.** A workload name that includes a timestamp or a random suffix makes every submission a different workload, and the copies accumulate exactly as an instruction would. - **A value read at authoring time.** A field filled in from the current clock, the current host, or the current output of some other system produces a different document on every render, so there is always a difference to act on even when nothing meaningful changed. - **Anything the spec cannot describe.** Effects that happen outside the declared state — a one-off action triggered as a side effect of the change — are not covered by the document's arithmetic and may well repeat. The pattern in all three is the same: idempotence holds exactly as far as *the same input produces the same document*. Anything that makes the document differ makes the comparison differ. ## Why interviewers like this question Because it is the most concrete consequence of the declarative model, and it has an observable answer. It is also the property that makes safe automation possible: a submission that timed out, a pipeline that ran twice, a retry after a network error — none of them need a "did it already happen?" check, because asking again for the same end state costs nothing. Platforms differ in the mechanics of how they detect and close the difference, and in whether they push the document out or pull it from somewhere, but every one of them relies on the same property of the document itself.

  • Does re-submitting an unchanged spec disturb the running copies?
    No. If no field differs from the stored document there is no difference to act on, so nothing is recreated, moved or reloaded. Re-submission is not a restart and is not a way to nudge a sick copy — that is a separate action with its own consequences.
  • What is the most common way teams author idempotence away by accident?
    By generating part of the document at submission time. A workload name with a timestamp or a random suffix makes every submission a new record, so copies accumulate; a field filled from the clock or from another system's current output makes a difference appear on every render even when nothing meaningful changed.
  • Does idempotent submission mean the outcome is guaranteed?
    No. It guarantees that asking twice means the same as asking once, not that the ask can be met. A document requesting more capacity than the cluster has is unsatisfiable however many times it is submitted; repetition is safe, not persuasive.

A pantry list that says "four tins of tomatoes" can be re-read every day and the pantry still holds four. A shopping note that says "buy four tins" leaves you with eight after the second reading.

saying these in an interview costs you the question

  • Thinks a second submission adds another set of copies
  • Says a declared copy count is an instruction to add that many
  • Believes re-submission needs a guard to check it has not run already
  • Claims every spec is idempotent, even one with a generated name
  • Confuses re-submitting the document with restarting the running copies