Loop Fragment vs. Decision Node: Choosing the Right UML Approach for Retry Logic without Duplicate Writes

Short answer: neither construct gives you idempotency, and neither one is the source of duplicate writes. UML 2.5 activity diagrams define control flow and token semantics only — they say when an action runs, not whether its effect is applied exactly once. The duplicate-write risk lives in the implementation, so the right move is to pick the notation that communicates retry intent most clearly (a structured loop node) and annotate the write action with the idempotency mechanism your system actually uses.

What each construct actually guarantees

Loop node with a counter guard. If the write action sits inside the loop body, it executes once per iteration — that is, once per attempt. That is normal retry behavior, not a duplication hazard. The guard controls how many attempts occur; it does not merge or deduplicate their effects.

Decision node with a guarded back-edge. Semantically this is the same loop written differently: each pass through the feedback edge re-invokes the write. The guard is the only thing preventing uncontrolled re-entry. It offers no extra protection — and readers frequently misread a back-edge as accidental re-entry, which is a real communication cost in reviews.

One terminology fix worth making before you commit: "loop fragment" is sequence-diagram language. In an activity diagram, the equivalent is a structured loop node (or an expansion region). Mixing the terms will confuse reviewers checking your diagram against the spec.

Answering your three questions directly

1. Does a loop with a counter guard invoke the write once per attempt? Yes — once per iteration, by construction. It does not guarantee once overall.
2. Can a decision-node guard prevent re-entry? The guard controls re-entry, yes, but it cannot distinguish "retry attempt" from "duplicate write." Both constructs are equivalent here.
3. Is there a UML construct for idempotent retry? No. UML has no built-in notion of idempotency, deduplication, or atomicity spanning multiple actions. You must model the mechanism explicitly or reference it.

How to model "write at most once despite retries"

The standard pattern is to push the guarantee into the modeled system and say so on the diagram:

• Model the write as a single action annotated with a constraint or note such as {idempotent — upsert keyed by requestId}, or
• Precede the write with a check action reading external state (already written?), with the write on the "no" branch, or
• If the counter update and the write must be atomic, group them and attach a note naming the enforcing mechanism — a database transaction, a unique constraint, or a compare-and-swap. An interruptible region can hint at boundaries, but UML provides no true atomicity primitive across actions.

Recommendation for your case

Use the structured loop node with the guard on the retry path, keep the write as one action inside the body, and annotate it with the idempotency mechanism. This states intent plainly; the decision-node back-edge adds nothing semantically and invites misreading.

Verify before finalizing

• Trace token flow by hand for 0, 1, and N retries on your diagram; confirm the write fires exactly once per attempt.
• Check your modeling tool's support for structured loop nodes, guards, and constraints — notation support varies across tools and UML 2.x minor versions.
• Confirm with the implementation team where idempotency is actually enforced (unique key, idempotency token, transaction) and make the annotation match reality.

One caveat: guards in UML are assumed side-effect-free. If your retry condition itself mutates state, that assumption breaks and the diagram will lie about behavior — flag that case for review.