Looking forward to the eventual open-source release of Quicksilver.
I simply persisted the config in Mysql and synced the data to redis. Then each server had a redis replica locally to allow fast reads from OpenResty (nginx+lua scripts).
The project never took off, it was just an MVP. But why would someone pick Kyoto Tycoon instead?
(It’s one thing to make a wrong choice, it’s another to think you can paper over those mistakes and they’ll go away.)
More constructively: what would you have picked back in _2011_ when Cloudflare was getting off the ground? Ideally, it needs to have a memcached like interface (for easy gets/puts from Lua + NGINX), still operate when disconnected from upstreams (CDN POPs can have unreliable upstream conns), be cheap/free in terms of CAPEX/licensing, and be optimized for (extremely) read-heavy workloads. Strong consistency is less useful here.
"Technical debt" only debt after the fact. Most of the time, it's the result of a series of (likely rational) trade-offs you've made given the current state of your business.
To answer your question:
> what would you have picked back in _2011_ when Cloudflare was getting off the ground?
Not only "would have" but did pick and use (well before 2011) an abstraction around SQLite because our team first evaluated our read vs write requirements and found it to be an adequate option rather than going crazy trying to find a nosql solution worthy of including on our resumes.
The Cloudflare article is somewhat skimpy on the details of their benchmark, so these numbers are not an exact equivalent but, here, I just threw this together: https://github.com/mqudsi/sqlite-readers-writers
P99.9 for reads with two writers is 2ms as compared to their 1215ms, and this is with full ACID compliance and write synchronization.
You don't need to be an expert in creating these systems, you just have to be able to test and validate your architectural decisions before building upon them. It takes only an hour or three to pick a library and write a similar benchmark for any KV store you're interested in (although the exact benchmark would have to be tweaked to match your expected needs).
(That said, lmdb is a great choice and I've recommended it here on HN before... except they ended up replicating on top of it a lot of what SQLite provides for free. Their transaction logs are almost like SQLite's WAL which I used in my benchmark, except going with SQLite would have skipped the entire second half of their Quicksilver solution since it they wouldn't need to manually handle transaction logs, split payloads, and manually reassemble to avoid fragmentation.)
 for example, strong eventual consistency approaches can solve pretty much all of their problems with fast reliable replication, but that requires engineers to be familiar with CRDT implementations and research on the subject in a pretty time consuming distributed systems field