系统添加的隐藏成本
Source: Dev.to
对添加的自然偏好强烈且普遍
从未接触过“添加”成本的软体工程师——通常是那些没有在早期创业公司工作的工程师——往往会增加复杂度，而不是降低复杂度（或至少保持不变）。
他们很少为自己添加的内容付出维护代价，因为在大型组织中，他们常常：
- 经常调动团队，使其他人承担他们造成的费用。
- 依赖 DevOps、Security 或 Finance 团队来分担部分成本。
- 专注于交付工单而非交付价值，因此没有意识到当前的工作是几个月前决策的后果，本可以避免。
系统性思维让工程师能够看到其添加的影响，不仅在短期内，而且在长期内，影响技术系统以及更广泛的组织“人际系统”。
在对解决方案进行成本‑效益分析时，必须考虑隐藏成本——即使这些成本以后不是由你来支付。作为价值创造者，你的目标是为周围的人节省时间、降低压力。
常见的隐藏成本添加
- 新的数据库
- 新的编程语言
- 新的框架
- 代码库中的新模式
- 新的外部服务
- 新的服务器间通信协议（例如 REST、SOAP、GraphQL、gRPC）或模式（例如 同步、事件驱动）
最被忽视的隐藏成本
- 新团队成员的更高上手成本
- 在该代码库或系统上工作时更高的上下文切换成本
- 更大的可能出错的表面面积
- 更大的需要监控的表面面积
- 需要设置的额外监视器
- 需要配置的额外警报
- 必须跟进的额外安全补丁和更新
- 可能导致停机的未知未知
如果把所有这些隐藏成本加起来，就会清楚地看到，你需要一个 非常充分的理由 来证明任何新增的合理性。这个理由应当与公司的长期目标和宗旨相一致，而不仅仅是当前工单的最佳解决方案。
Source: …
极端示例：单个 PostgreSQL 实例能否满足需求？
“不可能，我需要在大规模下处理支付，并且需要一个队列系统。”
回答： PostgreSQL 原生支持通过表存储支付事件，并使用SELECT FOR UPDATE SKIP LOCKED语义的消费者实现队列。
“好吧，但我需要 Elasticsearch 来进行模糊文本搜索。”
回答：pg_trgm扩展提供模糊和部分匹配、排序，甚至在 SQL 中直接实现词干提取。
“我们需要 MongoDB 来使用灵活的 JSON 文档。”
回答： PostgreSQL 的JSONB类型让你查询嵌套结构、为其建立索引，并与关系数据进行关联。
常见需求的 PostgreSQL 替代方案
| 需求 | PostgreSQL 解决方案 |
|---|---|
| 后台任务 | jobs 表 + SELECT FOR UPDATE SKIP LOCKED |
| 周期性任务 | pg_cron 用于原生调度 |
| 发布/订阅 | LISTEN / NOTIFY 用于轻量级实时通知 |
| 分析 | 窗口函数、CTE（公用表表达式）和物化视图 |
| 列式存储 | cstore_fdw 用于分析查询 |
| 机器学习 | MADlib 用于数据库内的回归和聚类 |
| ETL 与管道 | http_fdw + pg_cron 用于计划的摄取与转换 |
| 缓存层 | UNLOGGED 表或物化视图作为持久缓存 |
| 地理空间查询 | PostGIS 用于坐标、距离和形状操作 |
| 向量搜索 | pgvector 用于嵌入和相似度搜索 |
| 策略执行 | 行级安全（RLS）用于用户级访问规则 |
| 配置存储 | 带约束和历史记录的版本化配置表 |
| 审计 | 触发器 + JSONB 日志实现完整的变更历史 |
| REST API | PostgREST 自动暴露 CRUD 端点 |
| GraphQL API | Hasura 为 PostgreSQL 即时提供 GraphQL |
| 文件存储 | bytea 或大对象用于中小型文件 |
再次强调，这只是一个极端示例，并 不 表明将所有内容都放在 PostgreSQL 中是每种使用场景的最佳答案。它仅用于展示可能性，并挑战你在面对任何特定功能时思考：
“我如何在引入最少复杂度的前提下，实现此业务或技术目标，并且在当下和长期对我以及我的同事都保持可维护性？”
结束思考
在评估新添加项时，始终权衡隐藏成本与它们所带来的长期价值。目标是采用满足目标的最简方案，将更复杂的添加项保留给那些真正符合组织战略目标的情况。