Airbnb's config-delivery sidecar, sitar-agent, was fully rewritten from Ruby to Java in 2024 — and its local datastore moved off a Sparkey store that had to lock the whole file on every write.

Sitar is Airbnb’s dynamic configuration system: it lets engineers change critical feature configuration across thousands of services several times a minute, without redeploying anything. Delivering those changes is the job of sitar-agent, a sidecar that runs in every subscribed service pod and keeps configuration synced to the local filesystem. Its original datastore was a Sparkey-backed implementation with a thin wrapper layered on top for concurrent coordination.

In 2024, sitar-agent underwent a full rewrite from Ruby to Java, Airbnb’s mainstream JVM language — and the team used the rewrite to modernize the architecture alongside the language change. On pod startup, the agent now preloads a compressed snapshot from S3 before syncing with the Sitar Service, cutting cold-start time and decoupling startup from Sitar Service availability. After startup it polls the Sitar Service every 10 seconds with jitter, and a 10-second server-side cache plus change tokens keep most of those polls from ever touching the database.

For the local datastore, the team replaced Sparkey with SQLite running in write-ahead logging (WAL) mode, which supports concurrent reads during writes without a custom locking wrapper. Configuration changes now reach thousands of Airbnb’s service instances within tens of seconds, even with tens of thousands of pods polling simultaneously.

The team evaluated SQLite against RocksDB across dataset size, read QPS, and memory allocation. RocksDB won on raw performance — tested up to 1500 ops/sec with minimal degradation — but came with a heavier operational model requiring tuning of compaction, block cache, and column families, and a multi-language library ecosystem that was less mature and less uniformly maintained. SQLite’s read latency ran 2-3x slower than RocksDB’s, but the team judged that sufficient for sitar’s actual workload, and it kept first-class bindings across Java, TypeScript, Python, Go, and Ruby — every language sitar’s consumers use.

The rewrite also forced a decision on whether sitar-agent should stay a separate sidecar container or fold into the main application container as a library — the latter would have cut per-pod JVM overhead and removed a container for service owners to manage. Airbnb kept it as an isolated sidecar anyway: folding it in would have meant reimplementing sitar’s logic across Java, Python, Go, TypeScript, and Ruby, and losing the isolation that keeps a sitar bug or resource spike from starving the main application container. The projected cost savings weren’t enough to justify that risk and multi-language maintenance burden.

When your fleet speaks five languages, the “efficient” choice that only works in one of them isn’t actually efficient — it’s a maintenance bill due in the other four.