Yes, we are assuming a log that picks linearizability at the cost of availability under partitions. Like most logs do, including Kafka, Pulsar, RedPanda, etc.

The application state is defined by the log here, and the log drives retries/recovery, so it doesn't much matter if the process that executes the app code splits off. The log would hydrate another one.

Also the one log is at the granularity of a single key or handler execution. More of a logical log, than a physical log or even partition.

In Restate, we implement a logical log-per-key, backed by a partitioned physical log.

couldn't the log be synchronously replicated to multiple servers to increase A?

In case of mutation either the replicas will be out of sync (so no C), or you'll need to synchronously mutate the replicas (so bad A due to latency).

delaying writes by a factor longer than the max clock skew of the cluster is a pretty common strategy. It is what Google Spanner does.

Right but it's not magic as you cannot predict networking delays.

The max clock skew also has to pick between A and C, in underestimates you lose serializability, in overestimates you pay in write latency.

What if you use CockroachDB for your log? They do something pretty clever: https://www.cockroachlabs.com/blog/living-without-atomic-clo...

Thanks for the link, not much familiar with CockroachDB but I worked on a similar system that wanted to provide strong consistency when reading from many databases, some of which where Spanner but not all of them.

Eventually the system implemented something similar to "find transaction timestamp at execution time" + optimistic locking, as the article states you lose global linearizability and have to do some re-reads for writes.

What I missed the most from Spanner compared to the system above is that its tricky to do client-side transaction chaining where there are many clients and the order is important.

If you put a atomic clock like OCP-TAP Time Card with GNSS receiver in every server and use precision time protocol to sync them you should be able to synchronize quite a few servers to less than 100 nanoseconds.

If I've understood it, it's like using Kafka with 1 topic and 1 partition. But it shouldn't rule out multiple brokers with a >1 replication factor, giving you CP.

But can't any log be implemented as a CRDT? Was that not implied in the post? I didn't read it that close...

CRDT is really only useful when inconsistencies could be acceptable in some situations and so it depends on the application.

For something that is trying to solve the general problem of consistent single ground-truth log, you can't really do much better than Spanner.

the "conflict-free" in crdt is like miller high life being the "champagne of beers." it really means conflicts ignored and conflicting items discarded by established rules, which works well for some use cases, but for many does not.