Design in-memory threshold switcher

Quick Overview

This question evaluates a candidate's ability to design memory-aware control systems, covering skills such as hysteresis-based thresholding, dynamic runtime reconfiguration, thread-safe concurrency, low-overhead metric sampling, event-driven state notifications, and handling multi-process and failure edge cases.

Design in-memory threshold switcher

Company: Amazon

Role: Software Engineer

Category: System Design

Difficulty: hard

Interview Round: Technical Screen

Design an in-memory "switcher" component that toggles between ENABLED and DISABLED states based on runtime memory usage with user-configurable thresholds. Requirements: ( 1) Support separate upper/lower thresholds (hysteresis) to prevent flapping. ( 2) Allow dynamic reconfiguration at runtime without downtime. ( 3) Provide thread-safe reads/writes and low-overhead sampling of memory metrics. ( 4) Expose callbacks or events when state changes. ( 5) Define behavior under memory spikes, metric polling failures, and multi-process or multi-instance deployments. ( 6) Describe data structures, APIs, concurrency model, and monitoring/metrics. ( 7) Discuss testing strategy, performance considerations, and trade-offs of pull vs push metric collection.

Overview: This question evaluates a candidate's ability to design memory-aware control systems, covering skills such as hysteresis-based thresholding, dynamic runtime reconfiguration, thread-safe concurrency, low-overhead metric sampling, event-driven state notifications, and handling multi-process and failure edge cases.

|Home/System Design/Amazon
Amazon logo
Amazon
Sep 6, 2025
hardSoftware EngineerTechnical ScreenSystem Design
4
0

Design an In-Memory Memory-Pressure Switcher

Context

You are designing an in-memory component ("Switcher") that gates expensive work (e.g., request admission, cache growth, background jobs) based on the process's runtime memory usage. The switcher exposes an ENABLED/DISABLED state with hysteresis to avoid flapping and supports live reconfiguration.

Assume the switcher runs within a single service process by default, but may be used in multi-process or multi-instance deployments.

Requirements

  1. Hysteresis thresholds
    • Support separate upper and lower thresholds so the switch does not flap around a single boundary.
  2. Dynamic reconfiguration
    • Allow changing thresholds and behavior at runtime without downtime.
  3. Concurrency and performance
    • Provide thread-safe reads/writes.
    • Low-overhead sampling of memory metrics.
  4. State-change notifications
    • Expose callbacks or events when the state changes.
  5. Edge-case behavior
    • Define behavior under memory spikes, metric polling failures, and in multi-process or multi-instance deployments.
  6. Design details
    • Describe data structures, public APIs, concurrency model, and monitoring/metrics to expose.
  7. Testing and trade-offs
    • Discuss testing strategy, performance considerations, and trade-offs of pull vs. push metric collection.

Submit Your Answer to Earn 20XP

Sign in to leave a comment

Loading comments...