2026 on rusoblanco

Purity, Determinism and Idempotency Clearly Explained

Mon, 09 Mar 2026 12:00:00 +0000

The terms pure, deterministic, and idempotent are not synonyms. Each describes a different property of a function, and confusing them leads to sloppy reasoning about code. This post breaks down all three with concrete Python examples.

1. Two Kinds of Idempotency

The word “idempotent” has two distinct formal meanings, and conflating them is the root of many misunderstandings.

Value-idempotent (mathematical): f(f(x)) = f(x). Applying the function to its own output gives the same result. For this to be well-defined, the function’s input and output types must be exactly the same (an endomorphism, a -> a). These are projections — they collapse their input into a canonical form, and applying them again changes nothing. Examples: abs, upper, clamp. Counter-examples: negate, increment.

Effect-idempotent (imperative): Calling a function multiple times has the same effect on system state as calling it once. This is what matters for retries, APIs, and distributed systems. Examples: HTTP PUT, HTTP DELETE, upserting a database row.

The unifying intuition: doing it twice is the same as doing it once — applied either to values or to effects.

2. The Three Properties

Determinism. A deterministic function always returns the same output for the same input — across calls, across time, across machines. Nondeterminism creeps in whenever a function consumes a hidden input not in the argument list:

Hidden state — a database row, the system clock, an environment variable, a global counter. The value can change between calls, so the output changes too.
Pseudo-random number generators (PRNGs) — deterministic algorithms that become nondeterministic because they are typically seeded by a hidden input.
True random number generators (TRNGs) — hardware or quantum RNGs are nondeterministic by nature. There is no hidden input to expose; the output is genuinely unpredictable.
Concurrency — when threads share mutable state, the OS scheduler’s timing becomes an implicit input. Two runs of the same code can interleave differently, producing different results.

Purity. A pure function has two constraints: (1) its output depends only on its input arguments (which implies it is deterministic), and (2) it produces no side effects — no writes to disk, no mutations of external state, no network calls. Pure functions are referentially transparent, meaning a function call can be replaced with its return value without changing the program’s behavior. An impure function violates at least one of those constraints.

Idempotency. As defined in Section 1 — either value-idempotent (f(f(x)) = f(x)) or effect-idempotent (repeated calls leave state unchanged after the first).

All pure functions are deterministic. All pure functions are trivially effect-idempotent (no effects to repeat). But pure functions are NOT automatically value-idempotent.

3. How They Combine

Purity is the strongest property: it implies determinism and trivial effect-idempotency. But the reverse does not hold. Let’s walk through each combination.

Pure, Value-Idempotent

1
2
3
4
5
6


def normalize_email(email: str) -> str:
 """Strip whitespace and lowercase. f(f(x)) = f(x)."""
 return email.strip().lower()

assert normalize_email(" Alice@Example.COM ") == "alice@example.com"
assert normalize_email(normalize_email(" Alice@Example.COM ")) == "alice@example.com"

def normalize_email(email: str) -> str:
 """Strip whitespace and lowercase. f(f(x)) = f(x)."""
 return email.strip().lower()

assert normalize_email(" Alice@Example.COM ") == "alice@example.com"
assert normalize_email(normalize_email(" Alice@Example.COM ")) == "alice@example.com"

Pure, NOT Value-Idempotent

1
2
3
4
5
6
7
8


from urllib.parse import quote

def url_encode(text: str) -> str:
 """Percent-encode a string for URLs."""
 return quote(text, safe="")

assert url_encode("hello world") == "hello%20world"
assert url_encode(url_encode("hello world")) == "hello%2520world" # Double-encoded!

from urllib.parse import quote

def url_encode(text: str) -> str:
 """Percent-encode a string for URLs."""
 return quote(text, safe="")

assert url_encode("hello world") == "hello%20world"
assert url_encode(url_encode("hello world")) == "hello%2520world" # Double-encoded!

Double-encoding (%20 → %2520) is a real and common bug — pure, but not value-idempotent.

Impure, Deterministic, Effect-Idempotent

Like HTTP PUT — writing the same value again leaves the system unchanged.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


config_store: dict[str, str] = {}

def upsert_config(key: str, value: str) -> str:
 config_store[key] = value
 return f"OK: {key}={value}"

assert upsert_config("timeout", "30") == "OK: timeout=30"
assert upsert_config("timeout", "30") == "OK: timeout=30"

# State after one call or ten calls is identical:
assert config_store == {"timeout": "30"}

config_store: dict[str, str] = {}

def upsert_config(key: str, value: str) -> str:
 config_store[key] = value
 return f"OK: {key}={value}"

assert upsert_config("timeout", "30") == "OK: timeout=30"
assert upsert_config("timeout", "30") == "OK: timeout=30"

# State after one call or ten calls is identical:
assert config_store == {"timeout": "30"}

Impure, Deterministic, NOT Effect-Idempotent

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


audit_log: list[str] = []

def append_to_audit_log(event: str) -> str:
 audit_log.append(event)
 return f"logged: {event}"

assert append_to_audit_log("user_login") == "logged: user_login"
assert append_to_audit_log("user_login") == "logged: user_login"

# Same return value, but the side effect accumulated:
assert len(audit_log) == 2 # Not effect-idempotent!

audit_log: list[str] = []

def append_to_audit_log(event: str) -> str:
 audit_log.append(event)
 return f"logged: {event}"

assert append_to_audit_log("user_login") == "logged: user_login"
assert append_to_audit_log("user_login") == "logged: user_login"

# Same return value, but the side effect accumulated:
assert len(audit_log) == 2 # Not effect-idempotent!

Every call adds another entry — a retry produces a duplicate log line.

Impure, Nondeterministic, Effect-Idempotent

This is the classic case that confuses most developers.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


database: dict[str, str] = {"item_1": "Apple", "item_2": "Banana"}

def delete_item(item_id: str) -> int:
 if item_id in database:
 del database[item_id]
 return 200 # OK
 return 404 # Not Found

assert delete_item("item_1") == 200 # First call: deletes the item
assert delete_item("item_1") == 404 # Second call: item already gone

# But the state of the database is the same after both calls!

database: dict[str, str] = {"item_1": "Apple", "item_2": "Banana"}

def delete_item(item_id: str) -> int:
 if item_id in database:
 del database[item_id]
 return 200 # OK
 return 404 # Not Found

assert delete_item("item_1") == 200 # First call: deletes the item
assert delete_item("item_1") == 404 # Second call: item already gone

# But the state of the database is the same after both calls!

The return value changed (200 → 404), but the state of the system did not. Effect-idempotency is about the effect, not the output.

Impure, Nondeterministic, NOT Effect-Idempotent

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


_next_id = 0

def create_user(email: str) -> dict:
 global _next_id
 _next_id += 1
 user = {"id": _next_id, "email": email}
 # Imagine: database.insert(user)
 return user

first = create_user("alice@example.com") # {"id": 1, ...}
second = create_user("alice@example.com") # {"id": 2, ...}

assert first["id"] != second["id"] # Different output (nondeterministic)
# And two rows now exist in the "database" (not effect-idempotent)

_next_id = 0

def create_user(email: str) -> dict:
 global _next_id
 _next_id += 1
 user = {"id": _next_id, "email": email}
 # Imagine: database.insert(user)
 return user

first = create_user("alice@example.com") # {"id": 1, ...}
second = create_user("alice@example.com") # {"id": 2, ...}

assert first["id"] != second["id"] # Different output (nondeterministic)
# And two rows now exist in the "database" (not effect-idempotent)

A network retry creates a duplicate user — this is why payment APIs require idempotency keys:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


seen_requests: dict[str, dict] = {}

def create_user_idempotent(email: str, idempotency_key: str) -> dict:
 if idempotency_key in seen_requests:
 return seen_requests[idempotency_key]

 user = {"id": generate_id(), "email": email}
 # database.insert(user)
 seen_requests[idempotency_key] = user
 return user

seen_requests: dict[str, dict] = {}

def create_user_idempotent(email: str, idempotency_key: str) -> dict:
 if idempotency_key in seen_requests:
 return seen_requests[idempotency_key]

 user = {"id": generate_id(), "email": email}
 # database.insert(user)
 seen_requests[idempotency_key] = user
 return user

The first call creates the resource and caches the result; subsequent calls with the same key return the cached result and skip the write.

4. The Decision Tree

 flowchart TD
 A(["f(x)"]) --> B{"Is it pure?"}
 B -- Yes --> V{"f(f(x)) = f(x)?"}
 V -- Yes --> D1["Pure · Value-idempotent"]
 V -- No --> D2["Pure · Not value-idempotent"]
 B -- No --> F{"Same input →\nsame output?"}
 F -- Yes --> I1{"Same effect on\nrepeated calls?"}
 F -- No --> I2{"Same effect on\nrepeated calls?"}
 I1 -- Yes --> G1["Impure · Deterministic · Effect-idempotent"]
 I1 -- No --> G2["Impure · Deterministic · Not effect-idempotent"]
 I2 -- Yes --> H1["Impure · Nondeterministic · Effect-idempotent"]
 I2 -- No --> H2["Impure · Nondeterministic · Not effect-idempotent"]

5. Why This Matters

These distinctions have direct, practical consequences:

Pure functions are trivially testable (no mocks, no setup) and safely memoizable (@functools.lru_cache). Keep functions pure whenever possible.

Effect-idempotency is a design requirement for any operation that might be retried — HTTP handlers, message queue consumers, database migrations.

Value-idempotency matters for normalization and canonicalization. Value-idempotent functions can safely be applied “just in case” without worrying about double-processing.

Read-only operations are impure and nondeterministic, yet effect-idempotent — reading changes nothing. In HTTP/REST this category is called safe; safe operations can always be retried without risk.

Impurity is not evil, but it should be contained. Push side effects to the edges of your system.

Conclusion

Three properties, three questions:

Is it pure? Yes → automatically deterministic, trivially effect-idempotent. But check value-idempotency.
Same input, same output? Yes → deterministic. No → nondeterministic.
Same effect on repeated calls? Yes → effect-idempotent. No → not.

PACE Planning: Why Your "Solid" Backup Plan Is Probably Fragile

Thu, 08 Jan 2026 12:00:00 +0000

We tell ourselves we’re prepared. We have backups. We have redundancies. Software engineers pride themselves on avoiding Single Points of Failure (SPOF).

But often, when chaos actually strikes (a server outage, a natural disaster, or just a really bad Monday), we find our backup plans were little more than lists of things we hoped would work.

A framework exists to cure this optimism bias: PACE planning.

It originated in the military, specifically for Special Ops comms plans. I’ve found it to be an incredibly potent tool for engineering resilience and personal peace of mind. It transforms “trying to figure it out on the fly” into a structured algorithm for continuity.

Simply writing a PACE plan down on a napkin isn’t enough, though. If you don’t understand your dependencies, even a four-layer backup plan can collapse in seconds.

The PACE Breakdown

PACE is an acronym determining the order of precedence for methods used to achieve a critical goal, or “mission.” It forces you to define four distinct ways to get the job done:

P - Primary: The preferred method. It’s the most efficient, effective, and habitual way you execute the task.
A - Alternate: The iconic “Plan B.” It should be nearly as effective as the Primary, often running in parallel or available with minimal friction.
C - Contingency: “Plan C.” Here is where things get annoying. Ideally, the Contingency method is reliable but less convenient, slower, or more resource-intensive.
E - Emergency: The last resort. “Plan D.” usually serves as a break-glass method. It will likely be slow, expensive, or provide only minimum viability, but it prevents total mission failure.

One crucial nuance in the formal definition of PACE often gets ignored: the four methods must be “independent enough that failure of one does not break the others.”

That logical condition, independent enough, is the hardest part to get right.

When It Works: The Coffee Run

To see this in action, let’s apply it to a low-stakes, critical daily mission: Getting Morning Coffee.

Primary: The Espresso Machine (Fast, delicious, routine).
Alternate: The French Press (Slower cleanup, requires a separate kettle, but good quality).
Contingency: Instant Coffee (Tastes worse, requires boiling water, very fast).
Emergency: A canned energy drink from the fridge (Cold, different chemical profile, but delivers the caffeine payload).

Why is this a good plan? The dependencies are physically distinct. If the Espresso machine’s electronics fail, the low-tech French Press works. If the electric kettle breaks, you can boil water in a pot on your gas stove. If the power goes out entirely, the gas still flows to boil the water. If the gas line is cut, the cold energy drink in the fridge requires no heat source at all.

Getting a PACE plan right for small missions is easy because the physics remain visible to the naked eye.

Where It Breaks: Hidden Interdependencies

Trouble starts when we apply “Napkin PACE Planning” to complex systems like IT infrastructure or Incident Response where the dependencies are abstract and invisible.

Consider a scenario many of us face: Remote Incident Response.

The Mission: You are the on-call engineer. You need to SSH into a production database to clear a deadlock during a critical launch.

You feel safe. You scribbled down a PACE plan:

Primary: Home Fiber Internet (Wi-Fi).
Alternate: 5G Hotspot via Mobile Phone.
Contingency: The Coworking Space/Coffee Shop down the street.
Emergency: Voice call a colleague in a different region to dictate commands.

On the surface, this looks robust. Theoretically, you have three layers of redundancy before you have to resort to the awkward phone call.

The Event: A transformer blows, causing a wide-area power outage in your neighborhood.

The Cascade:

Primary Fails: Your router goes dark immediately. You switch to your phone.
Alternate Fails: Here’s the nuance. The local cell tower has a battery backup, so the signal is live. But 10,000 of your neighbors just lost their Wi-Fi simultaneously. They all switched to 5G at the exact same second to check Twitter and complain to the power company. The congestion is so high that your SSH packets are dropped.
Contingency Fails: You grab your laptop and run to the coffee shop. You forgot that “The Coffee Shop” shares a hidden dependency with “Home Fiber”: Geography. They are on the same electrical grid substation. The shop is dark and locked.

The Result: In under 60 seconds, your plan collapsed from Primary straight to Emergency. You are now clutching your phone, praying that voice traffic gets prioritized over the 5G data congestion that just killed your Alternate plan, hoping the call actually goes through.

The Transitive Dependency Problem

Why did the Remote Work plan fail while the Coffee plan succeeded?

It failed because we confuse Methods with Resources, and we ignore that dependencies are transitive.

On the napkin, we think: Primary Method -> Home Router (in this context “->” means “depends on”)

In reality, the dependency graph is transitive: Primary Method -> Home Router -> Power Grid

Map out the other methods, and you’ll see they all converge on the same transitive node:

Contingency (Coffee Shop) -> Shop Open -> Power Grid
Alternate (5G) -> Cell Tower -> Finite Bandwidth (An exhaustible resource shared by your neighbors, who are also reacting to the Power Grid failure).
Emergency (Call Colleague) -> Cell Tower -> Finite Bandwidth (Now competing with the congestion).

When we design systems informally, we act as if the failure of the method is the only risk (e.g., “The router broke”). We rarely model the failure of the transitive resources (e.g., “The neighborhood has no power”).

Visualizing the Failure

Graph these dependencies out, and the fragility becomes obvious.

Check the diagram below for two things:

The “Phone” bottleneck: Both your Alternate (Hotspot) and Emergency (Voice Call) plans rely on a single physical device. If you drop your phone in the panic, you lose 50% of your PACE plan instantly.
The Failure Cascade: The red nodes represent the root failure. When the Regional Power Grid fails, it knocks out the Primary and Contingency methods directly. But it also creates a massive spike in traffic that saturates the RF Bandwidth, effectively choking off your Alternate and Emergency channels.

 graph TD
 classDef method fill:#e1f5fe,stroke:#01579b,stroke-width:2px;
 classDef resource fill:#fff9c4,stroke:#fbc02d,stroke-width:2px,color:black;
 classDef failure fill:#ffcdd2,stroke:#c62828,stroke-width:3px,color:black;

 Goal((Mission: <br>Incident Response)) --> P[Primary: <br>Home Fiber]
 Goal --> A[Alternate: <br>5G Hotspot]
 Goal --> C[Contingency: <br>Coffee Shop]
 Goal --> E[Emergency: <br>Voice Call]

 subgraph "Hidden Shared Dependencies"
 P --> Router --> HomePower
 C --> ShopWiFi --> ShopPower
 
 A --> Phone
 E --> Phone
 
 A --> CellTower
 E --> CellTower
 
 CellTower --> RF[RF Bandwidth]
 
 HomePower --> Grid[Regional Power Grid]
 ShopPower --> Grid
 end

 %% The Cascasde
 Grid -.- |Failure Causes Congestion| RF

 class P,A,C,E method;
 class Router,Phone,CellTower,HomePower,ShopWiFi,ShopPower resource;
 class Grid,RF failure;

Awareness vs. Invincibility

Quick disclaimer before going further: You can always break a PACE plan if you zoom out far enough.

Dependency graphs are fractals. Dig deep enough and you’ll always find a shared dependency that can topple the whole stack.

If a massive earthquake forces you to evacuate your home, you aren’t going to have your morning coffee, regardless of whether you have a French Press or a gas stove.
If you suffer a medical emergency like a stroke, you won’t be clearing that database lock even if you have four different internet connections.

There’s always a “Black Swan” event (a meteor, a war, or biology itself) that creates a total failure state.

The goal of this exercise, and of the tools we are about to explore, isn’t to create a theoretically bulletproof plan for the apocalypse. The goal is to know the limits of the plan you do have.

We want to move from “I hope this works” to “I know exactly why this might fail.” We want to catch the preventable, logical errors like shared power grids so we aren’t blindsided by the mundane, all while accepting the risks of the catastrophic.

Beyond the Napkin

A PACE plan is only as good as the independence of its layers. If failure of the Primary layer triggers a condition that propagates down a transitive chain to kill the Alternate and Contingency layers, you don’t actually have a plan. You have a hallucination of safety.

For critical systems, we need to be able to mathematically prove that our “Plan B” is actually available when “Plan A” dies. We need to move from intuition to verification.

Next time, I’ll explore how we can use Formal Methods (specifically TLA+) to model these resources and find hidden problems. We will move beyond scribbling on napkins and start verifying our resilience strategies with the same rigor we use to verify distributed systems.

Stay tuned.