Airbnb's Sitar-Agent Keeps Kubernetes Services Configured at Scale

Airbnb has unveiled the technical architecture behind Sitar-agent, a Kubernetes sidecar component that pushes configuration changes to a massive fleet of services multiple times per minute. The system maintains access to configuration data even during outages and propagates updates across the entire microservices infrastructure within seconds.

Why a sidecar approach?#

Rather than embedding configuration-delivery logic inside individual application libraries, Airbnb runs Sitar-agent as a dedicated sidecar container alongside each application pod in Kubernetes. This design choice offers several advantages:

• Language independence: Services written in Java, Python, Go, TypeScript, and Ruby all access configuration the same way
• Operational simplicity: Centralizing the delivery mechanism means fewer duplicated implementations across teams
• Consistent behavior: All applications receive updates through an identical code path

Applications read configuration values from a local cache maintained by the sidecar, avoiding direct calls to a centralized configuration backend.

Major redesign improvements#

Airbnb modernized Sitar-agent through a comprehensive rewrite in Java and swapped out the underlying storage layer. Key changes include:

• S3 snapshot bootstrapping: Configuration snapshots are stored periodically in Amazon S3. When a new pod starts, Sitar-agent retrieves the most recent snapshot before syncing incremental changes from the backend—this approach reduces startup overhead and allows services to operate during central-system outages
• Storage migration: The team replaced Sparkey with SQLite after evaluating alternatives like RocksDB, prioritizing SQLite's concurrency model, operational simplicity, and ecosystem support
• Safe rollout strategy: Engineers used shadow-read validation and feature flags to test the new datastore before moving production workloads

How updates propagate#

Sitar-agent uses a pull-based model, polling the Sitar backend service approximately every ten seconds for configuration changes. Server-side caching and incremental change tracking limit load on the central service while still achieving propagation times suitable for real-time operational configuration adjustments.