liveBook · Manning

Idempotency

As explained in Refactoring to Rust

An idempotent system produces the same externally relevant result when the same task is performed more than once.

An idempotent system produces the same externally relevant result when the same task runs more than once. A mathematical function may be idempotent while its service is unsafe: repeated processes can still overwrite a shared output. section 8.2

Make repeated work safe by:

  • Giving each task or entity a unique identifier. section 8.2
  • Including a unique ID or timestamp in generated filenames so concurrent processes do not overwrite one another. section 8.2
  • Coordinating multiple workers through routing and system-level mechanisms, such as a load balancer. section 8.2

Concurrent image generation

Running two copies of an application can make both produce single.png, leaving one result after the files overwrite each other. Naming outputs with a unique ID or timestamp preserves each task's result. section 8.2

Listing 8.3 Console: Running multiple processes at once
python main.py & python main.py

Run the same Python process twice to reproduce the concurrent-work scenario that exposes unsafe shared outputs. section 8.2

How Refactoring to Rust covers it

How deep it goes
Distinguishes mathematical idempotence from service-level output safety, but stops short of specifying a full coordination protocol.
Examples
Uses repeated Mandelbrot renders that overwrite single.png, then proposes unique IDs or timestamps for filenames.
What you can do after
Operate/configure concurrent services with distinct task outputs that remain safe when processes repeat work.
How it connects
Connects idempotency with horizontal scaling, unique identifiers, timestamps, load balancing, and coordination.

Also explained in

Compare how 17 books explain idempotency →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Refactoring to Rust. The section links point to the parts of the book it draws on.