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