核心接口在大促期间需要降级，但降级开关打开后返回兜底数据导致用户投诉，如何设计分级降级策略和开关粒度？

这个问题我一般不会只做一个“总开关”，因为核心接口一旦统一返回兜底数据，很容易出现误伤，尤其是大促场景，用户看到的数据可能不准确，就会引发投诉。

我会把降级策略设计成“分级降级 + 精细化开关 + 可观测回滚”。

第一，先按业务影响做降级分级。

比如核心接口里面通常不止一个功能点，可能包括价格、库存、优惠、推荐、权益、营销标签等。我会先区分哪些数据是强一致、不能降级的，哪些是弱一致、可以降级的。

一般可以分成几类：

不可降级数据 ：比如支付金额、实时库存、订单状态、用户权益扣减，这类数据不能随便返回兜底，否则会造成资损或用户投诉。 可弱降级数据 ：比如推荐列表、营销标签、排行榜、个性化内容，可以返回缓存数据、默认数据或者直接隐藏模块。 可限流降级数据 ：比如非核心查询、复杂筛选、历史数据查询，可以对低优先级用户或非关键链路限流。 可异步降级数据 ：比如日志、埋点、通知、异步计算，可以延迟处理，优先保障主链路。

也就是说，不是接口整体降级，而是接口内部按模块、字段、依赖服务去降级。

第二，开关粒度要细，不能只有一个全局开关