Immutability: Why Shared Mutable State Is the Root of Most Concurrency Bugs

A bug surfaces in production. A discount applied to an order is sometimes zero, sometimes correct — and which one you get depends on the order the API calls happen to arrive in. The order-processing logic looks correct in isolation. Every test passes. The bug appears only under concurrent load.

After two hours, an engineer finds it: a shared DiscountCalculator instance caches its last computation in a mutable field. Two threads call it at once. One thread's result overwrites the other's before the caller reads it.

The fix is twelve characters — remove the mutable cache field, compute from inputs alone. The bug could not have existed if the function had been pure. This is the entire case for immutability: not elegance, but the elimination of a category of bug.

Two Definitions That Do the Work

A side effect is any observable state change a function causes beyond returning a value — writing a file, sending an HTTP request, updating a database row, modifying a field on a shared object. A function with side effects does something beyond computing its output.

A pure function has two properties: given the same inputs it always returns the same output, and it produces no side effects. Pure functions are trivially testable — no database, no network mock, no thread synchronisation. They are safe to parallelise — no shared state to corrupt. They are safe to memoize.

Immutability is the property of data that does not change after creation. Any operation that would "change" an immutable object instead produces a new object. Immutable data can be shared freely across threads with zero synchronisation, because no thread can modify it. There is no race condition possible in code with no shared mutable state — there is simply nothing to race on.

Functional Core, Imperative Shell

The architectural pattern that operationalises this separates pure logic from side effects. The core — validation, computation, decision-making — is pure functions on immutable data. The shell — database reads, HTTP calls, filesystem writes — is where every side effect lives. The shell collects inputs, calls the core, receives a result, and performs the necessary side effects.

# Core: pure, testable, no infrastructure needed
calculateOrderTotal(order, taxRates) -> Money

# Shell: side effects contained here
order    = database.fetch(orderId)       # side effect
taxRates = cache.get("tax_rates")        # side effect
total    = calculateOrderTotal(order, taxRates)  # pure
database.save(order.withTotal(total))    # side effect

calculateOrderTotal is tested with a constructed order and tax table — no mocks, no database setup, no async handling. The shell is covered by integration tests. The boundary is the design.

The Tradeoff: Correctness vs Performance

Immutability is AT9 (Correctness vs Performance) chosen on the side of correctness. Pure functions and immutable data maximise correctness: no race condition is possible, and tests are deterministic. The cost is performance — immutable structures that "modify" by copying use more memory than in-place mutation, and functional-style accumulation uses more stack.

But the cost is almost always smaller than intuition suggests, and almost always preferable to the alternative cost: debugging a race condition in production, at night, that reproduces only under load. The introduction's bug took two hours to find. The twelve-character fix took two minutes. That ratio is the tradeoff.

There is a second benefit — AT8 (Coupling vs Cohesion). Side effects create hidden coupling: two functions that both write the same file are coupled through that file, invisibly. Pure functions have no hidden coupling — every dependency is explicit in the parameter list. Moving side effects to the shell makes the coupling visible.

Where It Fails: Silent Corruption

Shared mutable state under concurrency is the most common source of FM9 (Silent Data Corruption) at the code level. Two threads reading and writing the same mutable field without synchronisation produce data that is neither thread's intended result — it is an interleaving of both. The corruption is silent because neither thread raises an error. The wrong value simply propagates downstream until a computation result is visibly wrong. This is exactly the introduction's bug: no exception, no crash, just an occasional zero discount.

The signal is precise: when a bug reproduces only under concurrent load but passes every single-threaded test, shared mutable state is the cause and immutability is the remedy.

There is a cost to watch — FM3 (Unbounded Resource Consumption). A naive immutable structure that copies an entire collection per modification allocates memory proportional to the number of modifications: a loop processing 10,000 events by building a new list each step allocates 10,000 lists. Persistent data structures — trees that share unchanged subtrees between versions — solve this, bringing the overhead down to O(log n).

Real Systems

Clojure makes all core data structures immutable by default, using structural sharing so a modification costs O(log n) memory, not O(n). Redux mandates immutable state updates — reducers return a new state object, never mutating the argument — which is what enables time-travel debugging and prevents exactly the introduction's class of bug. Apache Kafka's log is immutable: producers append, consumers read from an offset, no record is ever modified — which is what lets multiple consumer groups read independently. Git content-addresses every commit, tree, and blob; a commit object never changes, which is the basis of its distributed consistency.

The One Sentence

Immutability is not a style preference — it is the deliberate choice to trade a little memory for the elimination of an entire bug category, because shared mutable state under concurrency produces silent corruption that passes every single-threaded test, and the only reliable cure is to leave nothing for two threads to race on.