Design a controlled brownout mode customers can understand

• Rank capabilities by customer value, resource cost, legal necessity, and dependency. Define whether stale, omitted, approximate, or queued behavior is acceptable for each journey.

• Measure the resource saved and business impact for every candidate fallback. A brownout step must release the actual bottleneck—turning off a cheap feature is operational theater.

• Protect checkout correctness and latency, activate degradation by cohort or region, avoid oscillation, communicate material limitations, and preserve a reliable path to restore features.

• Create versioned degradation levels evaluated locally from a resilient control snapshot. Services implement typed fallback contracts; global admission and local saturation signals recommend a level, while operators retain audited override.

• Propagate the active level and fallback reason with requests and responses. Cache or precompute safe stale views, and durably record customer mutations that the product explicitly promises to process later.

• Brownout may weaken freshness and completeness, never transaction, authorization, pricing, or inventory invariants. If a promotion cannot be verified, omit it rather than guess.

• Use hysteresis and minimum dwell time so levels do not flap. Last-known-good policy works during control outage, and recovery enables one capability at a time while watching saturation.

• Degradation cannot disable fraud, authentication, consent, or tenant isolation unless a documented risk owner approved that exact mode. Clients cannot request a privileged lower-check path.

• Track active level, resource relief, fallback success and quality, conversion, customer complaints, and error budget by journey. Record why and by whom each transition occurred.

• Precomputing fallbacks costs steady resources but can prevent expensive peak overprovisioning. Compare the cost of reserved capacity with the measured revenue cost of each brownout minute.

• Automatic brownout reacts quickly but can make product decisions from noisy telemetry; manual control is slow during cascades. Use automated recommendations and bounded transitions, with human governance for high-impact levels.

• Implement and test one low-risk fallback at a time, shadow trigger logic, then rehearse with product, support, and incident command. Remove brownout paths that do not measurably release the constrained resource.

• Principal candidates make degradation a product contract, not a bag of flags. They quantify relief and harm, protect invariants, and design stable entry and recovery.

Interviewer evaluation rubric