# Design a distributed configuration service: system design interview question

> Versioned application configuration with fast fleet updates, current validation, and safe rollback during partial failures.

Source: https://sysround.com/questions/design-distributed-configuration-service
Updated: 2026-11-05


Difficulty: hard. Levels: Senior, Staff+.

## How the interviewer opens it

"Design a service that stores versioned application configuration and sends updates across a large fleet. It must support validation and safe rollback."

## What to clarify first

- Fleet and configuration scope
- Configuration size and history
- Traffic and read:write mix
- Latency and eligible instances
- Consistency and availability
- Validation and current requirements
- Release safety and status
- Rollback
- Durability and outages
- Access and exclusions

## Scope of a strong answer

Core requirements:

- Store and read configuration revisions for each service and environment.
- Validate each release against current requirements.
- Release updates in stages and report which revision each instance uses.
- Restore a retained revision after current validation.

Usually out of scope:

- Store and rotate secrets.
- Provide feature flags for individual users.
- Change configuration across several services in one atomic operation.
- Build the application metrics service.

## What interviewers probe

### Revision changes and rollback

Operators and automated controls can change the same scope. A delayed update can arrive after a rollback.

### Updates across the fleet

The service must reach many instances quickly without making application availability depend on control service availability.

### Validation and application

A document can pass old checks but fail current requirements. Application versions can also disagree about which configuration values they accept.

### Release safety and progress

Fast delivery does not prove safe application. Rejections and missing evidence must affect release status without changing the measured population.

## Common mistakes

- Clients use the document revision number as the update order and reject a valid rollback.
- The service commits release state and sends notices through unrelated writes, which can lose an update.
- The service trusts earlier validation after the schema, validator, or application versions change.
- Applications read related fields from different configuration snapshots.
- The release hides rejections by changing eligibility or treats receipt as successful application.
- A stale coordinator or delayed alert can replace a newer release.

## The bar by level

- **Senior:** Separates revision identity from control order. Covers durable notices, regional delivery, fixed eligibility, rejection status, canary gates, and current validation for rollback.
- **Staff+:** Defines authority across regions and controllers. Closes validation races with requirement changes. Handles new application versions, stale metrics, and incomplete evidence without weakening safety.

Practice this question with an AI interviewer: https://sysround.com/practice/new?problem=distributed-configuration-service


---
SysRound (https://sysround.com) is an AI practice tool for system design interviews. It has a voice or typed AI interviewer and a shared whiteboard. At the end, you get feedback on each skill and a model answer. The AI feedback can be wrong.
