Design a configuration subscription service

Quick Overview

This question evaluates skills in designing a distributed configuration and subscription service, covering API design, real-time notification semantics (delivery and ordering guarantees), versioning, concurrency and thread-safety, durability and recovery, multi-tenant isolation, security, and scalability concerns.

Design a configuration subscription service

Company: Amazon

Role: Software Engineer

Category: System Design

Difficulty: hard

Interview Round: Onsite

Design a configuration service/class that supports setting configuration values and allows applications to subscribe to specific keys or namespaces. When a value changes, subscribers must be notified promptly. Specify the API (set, get, subscribe, unsubscribe), notification semantics (at-least-once vs at-most-once, ordering, debouncing), and how to handle versioning, rollbacks, and partial failures. Address thread safety, concurrency control, persistence/backup, and access control. Discuss how you would scale to thousands of clients (fan-out strategy, caching, long polling vs WebSocket), and analyze time/space complexity of core operations.

Overview: This question evaluates skills in designing a distributed configuration and subscription service, covering API design, real-time notification semantics (delivery and ordering guarantees), versioning, concurrency and thread-safety, durability and recovery, multi-tenant isolation, security, and scalability concerns.

|Home/System Design/Amazon
Amazon logo
Amazon
Sep 6, 2025
hardSoftware EngineerOnsiteSystem Design
10
0

System Design: Configuration Service with Subscriptions

Context

Design a multi-tenant configuration service that stores key–value configuration and lets applications subscribe to changes for specific keys or namespaces (prefixes). When a value changes, subscribers must be notified promptly and reliably.

Requirements

  1. API surface
    • set
    • get
    • subscribe
    • unsubscribe
  2. Notification semantics
    • Delivery guarantees (at-least-once vs at-most-once)
    • Ordering guarantees
    • Debouncing/coalescing
  3. Versioning and change management
    • Versioning of keys
    • Rollbacks
    • Handling partial failures
  4. Correctness
    • Thread safety (client library and server)
    • Concurrency control for writes
  5. Durability and recovery
    • Persistence and backups
  6. Security
    • Access control and auditing
  7. Scale and performance
    • Scale to thousands of clients
    • Fan-out strategy
    • Caching strategy
    • Protocol choice: long polling vs WebSocket (and/or SSE)
    • Time/space complexity of core operations

Assume namespaces are path-like prefixes (for example, /env/prod/serviceA/). Specify assumptions as needed.

Submit Your Answer to Earn 20XP

Sign in to leave a comment

Loading comments...