Airbnb engineers have detailed the architecture of Sitar-agent, a Kubernetes sidecar that distributes dynamic configuration updates across tens of thousands of pods and processes configuration changes several times per minute. The system is designed to keep configuration data available during service disruptions while enabling updates to propagate across a large microservices fleet within tens of seconds.
The company modernized Sitar-agent through a Java rewrite, Amazon S3 snapshot bootstrapping, and a migration from Sparkey to SQLite. The changes were aimed at improving reliability, startup performance, and operational resilience while reducing dependence on centralized configuration infrastructure.
Sitar-agent is part of Airbnb's internal Sitar configuration system, which allows engineers to modify application behavior through configuration changes rather than service redeployments. Because configuration updates occur multiple times per minute across a large microservices environment, the company needed a mechanism to deliver changes consistently while minimizing dependency on centralized infrastructure.
Sitar config delivery lifecycle (Source: Airbnb Blog Post)
The sidecar runs alongside application containers in Kubernetes and serves configuration data locally through a shared filesystem and in-memory cache. Rather than requiring services to communicate directly with the configuration platform, applications read configuration values from the local sidecar. Airbnb said this approach provides language independence across its Java, Python, Go, TypeScript, and Ruby services while centralizing configuration delivery logic in a single component.
Bo T, Software Engineer at Airbnb, in a LinkedIn post,
Dynamic configuration is a foundational capability in Airbnb infrastructure, empowering us to adapt and deliver innovations quickly.
As part of the redesign, engineers introduced a snapshot-based startup workflow. Configuration snapshots are periodically generated and stored in Amazon S3. When a new pod starts, Sitar-agent retrieves the latest snapshot and then synchronizes incremental updates from the Sitar backend before allowing the application to begin serving traffic. According to Airbnb, this reduces startup overhead and enables services to continue operating even when the central configuration service is temporarily unavailable.
The engineering team also revisited the decision to use a sidecar architecture rather than embed configuration delivery logic in application libraries. While a library-based approach could reduce resource consumption, Airbnb concluded that maintaining a dedicated sidecar simplified operations, reduced duplicated implementation effort, and ensured consistent behavior across multiple programming languages.
Another major change involved replacing Sparkey, the agent's previous local datastore. Engineers evaluated both SQLite and RocksDB before selecting SQLite due to its concurrency model, operational simplicity, and broad language ecosystem support. To reduce migration risk, the team employed shadow-read validation and feature-flag-controlled rollouts before moving production workloads to the new datastore.
Airbnb also discussed its continued use of a pull-based configuration distribution model. Sitar-agent polls the backend service approximately every ten seconds for updates. The company reported that server-side caching and incremental change tracking help reduce backend load while providing update propagation times suitable for operational configuration management workflows.