In September 2025, I gave a talk on FoundationDB simulation and RocksDB at the Chroma office in San Francisco, hosted by Antithesis. You can see details of the event here: luma.com/vgehl2q3.
Unfortunately, there was no video recording uploaded for this talk. But here are the slides I presented:
‹ › 1 / 93 .slidedeck{margin:1.5em 0;--sd-line:rgba(128,128,128,.35);} .slidedeck *{box-sizing:border-box;} .sd-stage{position:relative;display:flex;align-items:center;gap:.4em;} .sd-main{flex:1 1 auto;aspect-ratio:16/9;background:#000 center/contain no-repeat;border:1px solid var(--sd-line);border-radius:6px;user-select:none;-webkit-user-select:none;} .
In July 2025, I gave a presentation at Adobe HQ in San Jose on detecting and self healing from gray failures in FoundationDB. The talk is embedded below:
Talk summary: Gray failures in FoundationDB are subtle performance degradations that, while not full crashes, impact system health and burden operators with manual intervention. This talk presents a simple yet effective self-healing mechanism designed to address such issues. We’ll demonstrate how we reused FoundationDB’s core architectural building blocks—such as unbundled roles, central Cluster Controller, transport layer latency metrics, and fast recovery—to implement a “complaining” algorithm where processes report slow peers, enabling automated detection and remediation, thereby significantly improving FoundationDB’s resilience and reducing operational load.
I was recently reading the paper: What Modern NVME Storage Can Do, And How to Exploit it. It provides a good overview of the state of current storage engines in different databases, and talks about linux I/O API options, trends in hardware, and how to leverage the full power of SSDs. It’s a familiar story: just like in the previous post we couldn’t saturate main memory bandwidth, here we aren’t able to saturate disk bandwidth.
TLDR You have a bottleneck in your system, you run top and see your system’s process taking 100% CPU. You then run top -H and see there’s this one thread keeping 1 CPU core totally busy. You run perf and get a flamegraph, you see some hot functions, you optimize them and you get slightly better performance - enough that your system can survive for a few more months and your customers are happy (for now).
I recently decided to leave Meta (called Facebook when I joined). Today is my last day. I have finished offboarding and spoken to a lot of colleagues, some of who have become close friends now. As I sit in the MPK17 coffee shop, I figured it’s a good time to reflect back on my time in the company as things are still fresh in my mind.
First of all, I am really proud of what my team and I achieved: we built a 0->1 streaming system that is powering use-cases like fleet wide distribution (across Meta’s data centers in all regions), control plane data indexing, etc.