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.”
The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.
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
The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.
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 ask about
- 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 (L5/E5)
- Separates revision identity from control order. Covers durable notices, regional delivery, fixed eligibility, rejection status, canary gates, and current validation for rollback.
- Staff (L6+/E6+)
- Defines authority across regions and controllers. Closes validation races with requirement changes. Handles new application versions, stale metrics, and incomplete evidence without weakening safety.