风控多方案设计案例：抓住矛盾点，而非表面差异

架构设计常遇到一类问题存在多种解决路径，需要设计多套方案供讨论选择——这里最容易犯的错误是设计出多个”雷同方案”。以金融业务里常见的风控场景为例：风控业务把主业务数据同步过来、计算一系列风险指标，多个候选方案往往只是数据同步方式的差异（用数据库厂商自带的同步方案，还是业界专业的同步方案）——这类方案表面不同，实际都只关注了数据的实时可用性这一个维度，称不上真正意义上的”好设计”。这类方案的共同缺陷是：数据分散在风控和主业务两个地方，无论实时性多高，只要主业务数据发生更改或撤销，风控这边的测算结果就无法实现强一致性、算不准。抓住这个真正的矛盾点（数据一致性 vs 实时可用性）之后，更好的方案设计应该围绕这个矛盾的不同侧重去展开：一个方案强调数据同步的实时可用性、牺牲高并发时的数据强一致性；另一个方案强调数据的强一致性、牺牲实时可用性；还有一种方案让风控和主业务共用同一个数据库，牺牲数据分布的灵活性，换取数据强一致性和实时可用性兼得。这是[[逆向思维的三种分类：反转型、转换型、缺点型|转换型逆向思维]]的应用——不是在原方案基础上小修小补出几个看起来不同、实则原理相同的备选项，而是先识别出系统内真正存在的矛盾点，再围绕这个矛盾的不同取舍方向去设计出真正有区分度的多个方案。可迁移启发：评审一份”多方案对比”文档时，先检查这些方案之间的差异是不是仅仅停留在”用哪个具体工具/供应商”这个表面层次——如果几个方案本质上都在同一个维度上打转（比如都只关心实时性），说明设计者可能还没有找到这个问题真正的矛盾点在哪里，方案的多样性只是表面的，没有真正覆盖不同的权衡方向。

结构图：

flowchart TB
  W["雷同方案(表面差异):数据库自带同步 vs 专业同步方案<br/>=都只关注实时可用性,忽略一致性矛盾"]
  W --> F["共同缺陷:主业务数据变更/撤销时,风控无法强一致→测算不准"]
  F --> M["找到真正矛盾点:数据一致性 vs 实时可用性"]
  M --> A["方案A:强调实时可用性,牺牲强一致性"]
  M --> B["方案B:强调强一致性,牺牲实时可用性"]
  M --> C["方案C:共用同一数据库<br/>牺牲数据分布灵活性,换取一致性+实时性兼得"]