工作第八年，参与过十几次技术选型。踩过 "为了新而新" 的坑，也见过保守到错过窗口期的团队。分享一下现在自己用的判断框架。 一、先问为什么 如果现有方案能解决问题，只是"不够优雅"，那多半不该换。选型的动机应该是能力缺口，不是审美。 二、把成本算全 学习成本：团队多久能上手并排障 运维成本：多一个组
《Designing Data-Intensive Applications》读了第二遍，这次记录第五章和第六章的要点。 复制：单主、多主、无主 单主复制最简单，写全部走主节点，问题在于主节点故障后的切换。多主适合多区域写入，代价是冲突处理。无主复制（Dynamo 风格）用 quorum 读写，听起
