Reactive variables do not stay local for long. Once state changes over time, depends on other state, crosses boundaries, and triggers other work, the program begins to carry distributed-system problems.

The article is about that transition: reactivity is not only a UI convenience or a local dataflow trick once updates have ownership, timing, fanout, ordering, and failure behavior.

Architecture noteOriginally posted 2022-04-27; expanded into a concise article on 2026-07-09.

Included: local reactivity, concurrent updates, process boundaries, ordering, fanout, liveness, and the Cartilage connection.

Article focus: reactive state that crosses time, dependencies, boundaries, and failure paths until it has distributed-system shape.

Local Reactivity Is The Small Case

A local reactive value changes, and dependent values update. Inside a small program, that can look like a convenience: less boilerplate, fewer explicit callbacks, and a cleaner way to keep derived state current.

The structure changes when the dependent work is not all in one place. If a value update can trigger work in another process, device, thread, service, region, or fabric cell, the program now has a distributed-systems question even if the source code still looks like reactive notation.

What Becomes Distributed

Ordering: which update happened first, and which dependent result is allowed to observe it.
Ownership: which process, region, or device is responsible for the value now.
Fanout: how many dependents receive the update, and what happens when one of them lags.
Liveness: whether the system can keep moving when a dependent process stalls or disappears.
Consistency: which values must agree immediately, and which values may converge later.

Why Concurrency Appears

Reactive programming implies concurrency because many updates can become eligible at different locations in the program. A single-core scheduler can serialize some of that work, but the model itself already contains more than one active place.

Once those active places become autonomous processes, hardware regions, browser workers, services, or machines, the source language has to carry more than dependency notation. It has to carry communication, timing, placement, and failure boundaries.

Cartilage Connection

Cartilage explores this problem as a visible fabric: a process-like tile or region can represent a reactive value or operation, and local ports define how configuration and state cross a boundary. The Cartilage Visual Language article decodes the rendered role alphabet used by that line of work.

The Useful Boundary

The important boundary is where a local update becomes coordination: ordering, consistency, fanout, retry behavior, and the user's ability to understand what changed and why.

That is why reactive programming and distributed systems belong in the same conversation. The first gives a compact way to express dependency over time. The second names the operating cost once those dependencies cross real boundaries.