Light Cone Consistency: I'll Take One Scoop Of Each

Swytch — Caching in Proper Time

SubscribeSign in

Light Cone Consistency: I'll Take One Scoop Of Each<br>Making Physics Your Database's Problem<br>Rob<br>Jun 03, 2026

Share

Physicists spent the better part of the last century proving there is no universal “now”. Two events that look simultaneous to you might happen in a completely different order to someone moving past you. Neither of you is wrong. This is traditionally known as “relativity” to us non-physicists out here in the world: time is relative.<br>Most of the time, as software engineers, we don’t even care that it exists. Relativity rarely interacts with our personal life (unless you have kids, then you’re constantly trying to guess the truth), so we think it doesn’t interact with our software either.<br>Thanks for reading Swytch — Caching in Proper Time! Subscribe for free to receive new posts and support my work.

Subscribe

I’m here to tell you … you’re wrong. It probably does if you have a single machine, and it absolutely does if you have more than one machine.<br>Computers operate at a timescale most humans cannot comprehend. The average compiled “if-statement” executes in nanoseconds — if that. Most computers in a network are separated by a distance of nanoseconds in the same rack (by distance, I mean wire-distance), microseconds between racks, and milliseconds across continents or oceans. We call this “lag” as if there is something you can do about it.<br>This is just a signal — electricity or light — moving at the speed of light through its medium (at some speed less than c).<br>Your computer can have likely done dozens, if not hundreds or thousands of operations in the time it takes a signal to arrive at a “distant” location … and it hasn’t even responded yet.

This means both machines could have received the same signal, reacted to it, and broadcast a message to each other before they even know they’re competing on the same signal.<br>To solve this problem gets to the very heart of consistency.<br>“Because”: it’s just a graph

Kaben Kramer and I just submitted a paper to DISC, formalizing a paper by Mark Burgess and András Gerlits. Mark suggested I write a blog post for people who don’t get excited about papers — so here’s the blog post that explains the whole paper. No complex math theory required: just plain engineering.

If you build a system, almost any system, you probably pass messages in that system — to the kernel when you open a file, read the clock, allocate memory, etc. Today, we’re not going to get into that level of detail, even though LCC applies there too, but let’s focus on the interesting stuff: distributed systems.<br>Light Cone Consistency asserts that every message-passing system, from the post office to conversations you have with friends to the CPU cache to distributed systems builds an implicit causal system: if you draw an arrow between cause and effect over time, you get a graph. This graph is acyclic — because you can’t go back in time — and only grows forward. Essentially, a graph of “this, because that”.<br>Every machine in this system only sees part of that graph. It sees what messages have reached it, and nothing more. Everything it knows, it knows from those messages.<br>When two messages become concurrent (such as the image above — messages m’ and m’’ cannot causally relate to each other since the light cones didn’t overlap), you end up with a “fork” in the graph. In this model, concurrency is geometry.<br>The two knobs

If forks in the graph are unavoidable, consistency comes down to two decisions about how you handle them.<br>First: before you can act on a message, what else do you insist you’ve already seen? Nothing? Just other writes to the same object? Other writes in this session? Or the whole causal history behind it? We call this Causal Closure.<br>Second: when you hit a fork (two concurrent writes with no natural order), do you enforce an order anyway and how far do you go to enforce it? Order nothing? Order writes to the same object? Order everything? We call this Fork Resolution.<br>With these two dials, plus a couple of implementation details (what you report to the user based on what you’ve seen and how long you’re willing to wait to do so) … you can describe everything from serializable consistency all the way to eventual consistency.<br>This also allowed us to generate consistency models that nobody has actually named yet.<br>Tuning the knobs

The two dials look independent. And they are, unless you want to do something useful, like to use it to store data beyond just a log of data.<br>Once you enable that constraint, you want your ordering to respect causality: what we call “refining causality”. And to do that, it means you have to hold on to that causality which costs memory because you cannot refine information you don’t have.<br>Put plainly: a system that orders causality honestly is, for free, a system that remembers its causes.<br>The consequence of this is somewhat obvious: to resolve whether...