Long story short, I think what users really want is linearizable reads from secondary servers. It's something I'm interested in researching.

Thread-local causally-consistent sessions was an idea we considered very, very hard. Our CTO (Eliot Horowitz then) shot it down as "magic". Plus, it wouldn't solve the main problem, which is multi-tiered apps where one logical operation which should be causally consistent uses several MongoClients.

1. Agreed. Alas we've now released the API and it's annoying to users to change it.

2. Interesting. Causally-consistent sessions should only be used by one thread at a time, so if you initiated a MongoClient with "causal=True" then you shouldn't use it with multiple threads. Not an awful idea tho.

Oh, that's a useful feature. You can enforce causal consistency in general (which includes read-your-writes and other guarantees) with that mechanism. We've had that in MongoDB for some time, though, and customers have found it hard to use: emptysqua.re/blog/how-to-...

Couldn’t you run a bunch of YCSB clients to fix this? Also, we have a modified version of YCSB that replays traces and support open-loop replay (though our validation tests focused more on the replay accuracy than on evaluating the limits of the open loop implementation). github.com/disel-espol/...

KV-replay looks great! That allows us to use real-world arrival times in a performance benchmark. Seems like a great way to test a system's resilience, e.g. by reproducing loads that crashed the production system and experimenting with mitigation strategies.

I think more clients is better, but it's still fundamentally a closed system model: if a request is slow, that delays future requests from starting. Whereas a truly open loop benchmark starts requests at random, independent of how slow the previous requests were. Do you agree or am I wrong?

The "Open Versus Closed" paper was in 2006. The "coordinated omission" talk was in 2012. So why haven't we all switched to open loop benchmarks by now?

People don't talk enough about that movie.

See the blog post for more details, and read the paper on Arxiv for *all* the details. emptysqua.re/blog/leasegu...

@muratdemirbas.bsky.social and I are announcing today our new lease protocol for Raft, LeaseGuard. It's rigorously specified in TLA+, it's surprisingly simple, it adds no new messages to Raft, and it has cool optimizations to restore read and write availability quickly after a leader crash.

In practice, Raft systems implement leases wrong, or they use slow and expensive quorum reads, or they don't guarantee Read Your Writes at all.

"A napron" was once proper English.

You make partner at the right law firm, son, and you'll be riding the gravy train.

It's so disappointing that marijuana didn't substitute for alcohol.