An Origin Story

Setting: 2018, on an airplane, somewhere over the Pacific Ocean.

I woke up with a start, disoriented and slightly nauseous. The plane was in the middle of a long flight, and the turbulence had woken me from a deep sleep. I rubbed my eyes and looked out the window, trying to orient myself amidst the endless expanse of the clouds and ocean below. The plane bucked again, and I clutched at the armrest, still disoriented. I took a deep breath. Asked myself, “Are we going to crash?”

The airplane was completely fine. I was fine. Everything was fine. But, what if it wasn’t?

That thought would eat at me for the rest of the 34 hour flight. How would my wife know my passwords to pay the bills? There were so many things I wanted to tell my wife, my three year old son. I’d never be able to congratulate him on graduating school, on becoming a dad, or anything. I’d be gone. Just gone. A memory.

I suppose that is true for all of us.

One day it is our turn to make space for the young. But I could do better.

Solving People-Problems with Technology

I’m a software engineer. More specifically, I solve people-problems with technology. It’s what I do.

And this. This is a perfect people-problem: send an email to my son in 25 years.

Simple. Easy.

Right?

In a week, I had the first version running on my laptop. If I didn’t open my laptop for more than a few days, an email would be sent to my family to check on me. After two weeks, everything would be sent to my wife. Passwords, documents, access to everything.

That solved part of the problem. But I still couldn’t reliably send my son an email in 25 years:

1. My son didn’t have an email address.
2. Even if he did, would he still have access to that email address?
3. Would email still be around in 25 years?
4. Would the internet, as I knew it, still exist?

I needed something to store the letter in. Something that would never die, always be available – even when parts of it are offline. It needed to outlive me, with zero maintenance.

A Solution Does Not Exist

I would spend a large part of the next year hunting for a database solution that would work for me:

1. Always available
2. Strongly consistent
3. Distributed

Did you know? It didn’t exist (foreshadowing: yet). In fact, literature seemed to suggest that such a database couldn’t exist.

It was 2019. I knew that if I wanted to have this, I’d have to build it myself. I just didn’t know where to start.

Building The Universe

Also, in 2019, I was building a pretty neat game. The idea was simple: you build a space probe that can accelerate at insane speeds, going through a wormhole out in the asteroid belt to explore the universe and map out a constellation of wormholes.

One of the interesting bits is that due to the speeds of these probes, I was also modelling relativity on the probes and masking time dilation effects with latency. It was pretty cool, and I was able to model our entire solar system (non sequitor: did you know if our moon didn’t exist, the Earth would fly off into space?)

This got me entrenched in the realm of relativistic effects. It was fun and hard; trying to design gameplay around constraints that exist in the real world but don’t exist in the game.

I was using a mix of Go and PHP to build the game, and around the start of COVID-19, I discovered FrankenPHP and immediately started contributing to it.

Kévin Said Something

Fast-forward to 2024, I was sitting in a keynote at a conference, as a FrankenPHP contributor. Kévin said something on stage and it was like a lightbulb went off in my head. I knew how to make it. I can’t remember what he said though. Which is a shame.

I spent most of the next year working on a new kind of consensus algorithm, based on Paxos. I called it AtlasDb – and yeah, there were a couple of projects named that; apparently.

I kept at it until spring of 2025. I kept running into a problem building a distributed database: how the hell do you keep the cache coherent?

See: databases can be distributed. They could always be distributed one way or another since replication is a thing. Caches? Not distributed.

Sure, you can shard caches. But a world-spanning cache? That’s a problem. Some might say, it’s an impossible one.

As engineers, we either forgo the cache in this case, or we accept that it is just going to be janky sometimes; held together with duct tape and glue code.

It was working on the cache for AtlasDb’s engine … that I realized I had a solution. I was building a distributed cache engine already.

Defying CAP

I had a prototype by December 2025 – and it worked. It also appeared to violate CAP. The CAP theorem states that a distributed system cannot simultaneously provide consistency, availability, and partition tolerance. My solution allowed for all three – but first, I needed a name. And this, this really is the hardest thing in Computer Science – naming things. I decided on Swytch . How it works … is pretty cool actually.

Everything that happens in Swytch is called an “effect”. If you’ve ever worked with Event Sourcing, you’d recognize them as “events” to some degree. However, what makes an effect different from an event:

1. every effect carries what was observed
2. every effect carries semantics, not (always) data
3. every effect is composable with another effect

In a lot of ways, these are a different kind of CRDT than you’re used to – ordering matters, but the ordering is encoded in the structure. They compose into what I called a “causal log”: a log of everything that has ever happened.

Every write to a node computes one or more effects and then broadcast to the cluster. So long as we have causal closure (the ability to form a causal ordering), we have availability and consistency. During partition, we have still that. And because all effects are composable with another effect … well, it just works™️.

But wait – that’s not what I wanted. That sounds like eventual consistency with extra steps. I said I wanted strong consistency.

Well, you can have that too! It turns out that Swytch can provide any consistency you want, short of full linearizability (which is mathematically impossible for any distributed system).

Actually, CAP doesn’t apply

But wait! That should be impossible! This resulted in further research over the last few months. How was it possible? We wrote a paper on the topic, it’s on arXiv .

The paper explores what we’re calling Light Cone Consistency (or LCC for short). It’s an aggregate of all consistency levels and explains how they work together. LCC shows us that any consistency model must operate between three parameters:

• Causal Closure (C)
• Ordering Resolution (O)
• and, Timeliness (R)

Combining these parameters, we find three problems in distributed systems, all aptly named:

• CxR => CAP
• OxR => FLP
• CxO => AFC

The reason we never hit CAP, even with a partition and strong consistency is because the engine itself doesn’t constrain R. It can never hit CAP. Instead, we lose causal closure or ordering resolution. We hit AFC. We lose the ability to serialize our data.

And when that happens: we end up with split brain, but we still have availability. At that point, we have two choices:

1. intentionally disable ourselves to emulate CA (what Swytch calls safe mode)
2. allow the database to become holographic (what Swytch calls holographic mode): two independent databases that require human intervention to merge

If we know that one side will never write to the database, we can safely enable holographic mode, giving us an AC database on the writers side, but AP on the other side of the partition. They’re completely independent databases that happen to share a history together. If they reconnect and merge safely, you’re back to a full cluster.

Anyway.

Let’s put the weird and interesting stuff behind us. Read the paper, download Swytch .

I’ll be waiting in the comments.

The Inevitable Always Comes

So, what about that letter? That letter lives in Swytch. It’s one of the clusters on the community stats . Even if the internet falls down completely … as long as the power is on somewhere, the letter will survive.