SYSTEM Cited by 1 source

Sitar (Airbnb dynamic configuration platform)

Sitar is Airbnb's internal dynamic configuration platform. It manages runtime configuration (feature flags, tunables, rollout controls) for Airbnb services at scale, with a Git-based change workflow, staged rollouts, and a sidecar-based distribution mechanism.

Architecture (4 layers)

1. Developer-facing layer — GitHub Enterprise PR/review flow by default; sitar-portal web UI for teams that prefer a portal experience and for operational needs (emergency updates that bypass CI/CD, admin ops).
2. Control plane — schema validation, ownership/ACL enforcement, rollout orchestration (env, AWS zone, Kubernetes pod %, progression, rollback rules), and in-flight routing to specific environments or "slices of subscribers" for fast testing.
3. Data plane — source of truth for config values + versions; reliable, consistent, fast propagation to services. Internals not disclosed in the Feb 2026 post.
4. On-service: an agent sidecar runs alongside each service container (language-agnostic), periodically fetches subscribed configs from the data plane, and persists a local cache. Client libraries inside the service read the local cache in-process with optional fallbacks. Backend outages don't stop services — they keep running on last-known-good configs.

Key design choices

• Configs as code with a Git-based workflow. PR → mandatory review → schema validation in CI → merge → CD. Configs grouped into tenants (theme + owners + custom tests + dedicated CD pipeline).
• Staged rollouts + fast rollback. Every change starts in a limited scope, expands gradually; each stage evaluates regressions and notifies author/stakeholders.
• Separated control and data planes. "Decide" vs "deliver" can evolve independently.
• Local caching and resilient clients. Sidecar + on-disk cache + in-process client library reads → survives backend degradation.
• Emergency escape hatch. sitar-portal can push config updates that bypass normal CI/CD; fully auditable after the fact.

Per-team flexibility

Each team picks: automatic / manual / cron rollouts, rollout strategy, extra custom checks. Shared platform guardrails without one-size-fits-all flow.

Integration with incident response

Config events are emitted to observability tooling so responders can correlate production changes with bad configs quickly, then mitigate via the portal's emergency flow.

Seen in

• sources/2026-02-18-airbnb-sitar-dynamic-configuration — primary architecture description

Open questions (not answered in the post)

• Data-plane storage backend (etcd? internal KV? S3+CDN?).
• Push vs pull to the sidecar; propagation latency SLO.
• Handling of very large configs (JSON blobs, allowlists) vs small flags.
• How "slices of subscribers" are defined and targeted.