77 篇内容
文章介绍 GitHub 为应对 Agent 驱动的高并发读写而设计的新一代 Git 存储架构“Rubicon”。其核心是减少协调、将存储与计算解耦：利用 Git 对象不可变且按内容寻址，只对引用更新排序，Pack 等对象存入 Azure Blob，引用与 Pack 清单由独立复制的日志服务 Ref-CAS 以比较并交换提交。读请求先向 Ref-CAS 校验版本，未变化时无需拉取引用；压缩与垃圾回收由后台专用节点按分片租约执行，避免占用服务副本 CPU。内部测试覆盖单仓库 5000 个并发 Agent、7200 次推送/秒和稳定读延迟，但该架构尚处有限私有预览，部分读取与 Git 优化仍在规划中。
推荐收录，因为它不仅给出架构目标，还复盘了写前日志与分段 Blob 原型在写吞吐和读延迟上的取舍，并说明 Ref-CAS、虚拟副本和后台压缩如何分别扩展。对分布式存储、后端平台和大型代码托管系统的工程师有较高迁移价值；需注意实现绑定 Azure 与 GitHub 内部服务，且目前仅有限预览。
文章介绍 vLLM 为 Kimi K3.1 Pro 提供 Day-0 推理支持，重点解析该 2.8T 参数 MoE 模型在 1M 上下文下的稀疏注意力（DSA）服务优化。作者说明将 MLA latent、索引键和 KDA 状态打包进统一 KV cache，并用 token 分片 prefill、DCP 下的精确 top-k 合并与融合 DSA decode 路径降低长上下文延迟和显存占用。文中给出 8×GB300 等硬件上的 TTFT、TPOT、吞吐与 AgentX 基准数据，还覆盖 DSpark 推测解码、零偏差 RL、AMD/TPU/PPU 后端。结论是这些优化在长上下文和高并发 agent 场景收益明显，但数据来自厂商自测，且部分依赖特定硬件、内核与预览版投机模型。
推荐收录：文章没有停留在模型发布，而是具体拆解了混合 KV cache 布局、token 分片 attention、DCP 精确 top-k 合并和融合 decode 等可迁移的推理系统设计。适合 LLM 推理基础设施、GPU 内核与长上下文服务优化读者参考；主要风险是 vLLM/NVIDIA 等厂商自测基准，硬件与版本约束较强，需结合独立复现判断。
Meta 的 F3 把广告排序模型所需的上万特征编译成共享 DAG 合并图以提升服务效率，但合并图同时是发布单元，任一特征定义或模型测试失败都会阻塞整个流水线。F3 Lightning 将部署边界与执行边界拆开：每个特征独立编译、校验、发布和回滚，服务启动时再用内容派生的稳定标识、全局执行计划与拓扑排序合并共享计算，并通过单请求共享内存缓冲和稠密索引映射降低重复计算与缓存缺失。线上结果表明，同类特征到达生产约快 3.6 倍，且基础设施算力成本不增加。该方案适用于高并发 ML 特征服务平台，但高度依赖 Meta 的广告特征规模和运行时约束，文章未充分讨论跨机房容灾与长期维护成本。
推荐收录。文章以 Meta 广告 ML 特征服务为真实场景，完整呈现了从合并图全量发布瓶颈到独立发布、启动期共享执行、共享缓冲区和稠密索引的工程演进，并报告 3.6 倍发布提速且算力不增。对构建大规模特征平台、ML 基础设施和低延迟服务的读者，“部署与执行解耦”“启动期做不变工作”“内存布局影响 CPU”三条经验可直接迁移；但需注意方案依赖 Meta 的规模和运行时，不能简单照搬。
Cloudflare 复盘 DNS Zone Builder 将全量重建改为可证明安全的最小定向构建：事件携带变更字段，规划器按资源、元数据、apex、purge、全量五类选取工作，并处理同名多区域共享元数据、执行前快照和 Kafka 软提交。统一调度器合并同区域事件，在无法证明等价或首次发布时回退全量；超过记录阈值的大区域则避免不可完成的全量构建。生产数据显示 92.95% 构建避免全量，全量构建占比降约 40%，峰值内存降 85%，p99 完成延迟尖峰从 14.6 分钟降至 1.21 分钟，中位延迟从 7.7 秒降至 3.3 秒。文章说明了剩余全量构建、镜像对比与等价性测试的验证边界，指标不构成单区域延迟保证。
推荐收录，因为文章给出了从事件建模、最小安全构建规划、执行前快照校验到 Kafka 软提交与镜像等价的完整工程闭环，并有 92.95% 避免全量、峰值内存降 85%、中位延迟减半等生产数据支撑。适合分布式系统、基础设施和状态同步管线的架构师与 SRE 阅读，其“用保守回退换取正确性”“先验证等价再放量”的方法可迁移；主要局限是强依赖 Cloudflare 的 Quicksilver、Kafka 分区和区域模型，不能直接照搬到普通系统。
文章围绕分布式数据库的分片设计展开，核心论点是分片不应从表结构出发，而应从高频查询和事务共享的键出发，把相关表放入同一 shard group。文中以 storefront 为例说明如何用 xxhash 和 customer_id 定义默认 shard index，并通过 key_ranges 将 64 位键空间划分到物理 shard；customers 表可继承默认索引但改用 id，使订单、商品、地址共置。文章还讨论 reference tables 全量复制、按 SKU 的独立 shard group、SQL 表达式分片键、range/modulo 索引，以及无分片键查询使用 GSI 以两次单分片读取替代全分片扫描。边界方面，它强调跨分片事务不具备原子提交和共享快照，modulo 扩缩容会移动大量行，且内容绑定 Neki/PlanetScale 的配置与工作流，缺少通用基准验证。
推荐收录。文章用可执行的数据拓扑配置和具体查询样例，展示了查询驱动分片、共置、参考表、GSI 与扩缩容工作流之间的取舍，并明确指出跨分片事务和 modulo 的代价。适合正在设计或评估分片 PostgreSQL 的架构师、DBA 和后端工程师，其“先找查询共享键再定表”的方法可迁移到其他分片系统；需注意语法和迁移流程绑定 Neki/PlanetScale，且无独立性能基准。
文章介绍 GitHub 将海量 Git 仓库迁移到 Azure 时，最后一批高负载仓库受跨区约 25ms 往返和仓库级 quorum 串行写限制的问题。作者把写一致性范围从整个仓库缩小到单个 reference，使不同分支或引用的写入可并发，内部真实流量测试显示不同引用写入吞吐提升 3–4 倍且延迟更低。随后把 Azure Blob Storage 作为 virtual replica 纳入 quorum，写需在对象存储持久化后才确认，并引入无状态 virtual read replicas 独立扩展读、以对象存储为真源后台对账。文章也明确该读副本暂不适合所有读负载，写吞吐仍受 quorum 和全量副本约束，后续需重构提交协议与引用状态存储。
推荐收录。文章基于 GitHub 真实迁移约束，给出 per-reference quorum、virtual write/read replica 等可迁移设计，并用内部负载测试数据说明吞吐与延迟收益；适合分布式存储、云基础设施和平台架构读者参考。需注意它披露的是阶段性方案，读副本后台对账和写吞吐上限仍存在明确边界。
文章记录 ClickHouse 在 NVIDIA 早期 Vera CPU 上的性能测试，先运行 ClickBench，再用 1TB、625 亿条随机字符串的内存表构造过滤、聚合和连接三个微基准。测试比较不同 max_threads 下的耗时、加速比与效率，发现三类查询在物理核范围内近线性扩展，超过 176 个物理核后 SMT 对计算密集查询收益有限。简单 LIKE 查询在约 900 GB/s 处受内存带宽限制，正则过滤和聚合仍可继续利用更多核心；EXPLAIN PIPELINE 展示了算子级并行方式。SIMD 开关实验显示 NEON/SVE2 自动向量化带来约 3.5 倍差异。局限是合成数据、全内存、无压缩且基于早期硬件，不能直接代表生产 MergeTree 或完整 ClickBench 端到端表现。
推荐收录。文章给出可复现的 SQL、数据规模、线程扩展曲线和 EXPLAIN PIPELINE，具体展示了高核 Arm 服务器上数据库从内存带宽瓶颈到 SMT 收益衰减的定位过程，适合数据库内核、性能工程和基础设施选型读者。需注意其结论来自全内存合成基准和早期 Vera 硬件，生产环境应结合磁盘 I/O、压缩和真实查询进一步验证。
文章反对在 Postgres 中轻率使用 ON DELETE CASCADE：多级级联删除会在单事务内产生大量死元组、索引更新和 WAL，并对所有涉及表持有 RowExclusiveLock。迁移中的 ALTER TABLE 需要 AccessExclusiveLock，会被长时间级联删除阻塞，导致写入堆积甚至拖慢同步复制；未索引外键还会让单行删除退化为全表扫描。逻辑复制也有陷阱：订阅端默认跳过外键触发器，未完整发布外键树或缺少 replica identity 会产生孤儿行或删除失败。作者因此建议用 deleted_at 软删除、后台分批清理并保持事务短小。该方案需要应用读取过滤和清理任务，主要适用于 Postgres/OLTP 大规模删除场景。
推荐收录：文章用具体的锁链、WAL 放大和逻辑复制触发器行为，解释 ON DELETE CASCADE 从便利设计演变为线上故障的路径，并给出软删除与分批清理的可执行替代方案。对负责 Postgres 模式设计、迁移和规模化删除的后端/数据库工程师尤其有用，其中“保持事务短小且有界”的取舍可直接迁移；但方案要求应用层读取过滤，落地成本需单独评估。
文章复盘商业航天公司把卫星研发时序数据从 InfluxDB 2.x 迁至自托管 GreptimeDB 的案例。单次实验超 30 亿行，原系统出现查询 OOM、开源版不能横向扩展、bucket 数量受限和 Flux 使用门槛高，InfluxDB 3 Core 的库表列上限也不符合按实验分库、按对象建宽表的设计。团队评估 ClickHouse 与 VictoriaMetrics 后选择 GreptimeDB：改造 Vector 经 gRPC 写入，以 tag_/field_ 前缀做 schema 映射，按数据库统一 TTL，临时数据首写自动建表加列，并用 SQL 统一查询指标与日志。文章区分了固定 schema 的治理数据和自动扩展的临时实验数据，但作为厂商访谈，缺少迁移后的独立性能对比与失败细节。
推荐收录。文章给出了 30 亿行级实验数据下 InfluxDB 的具体约束、选型对比、Vector 写入 schema 映射、TTL 与自动建表加列等可迁移设计，适合时序数据库选型、可观测数据平台和航天/实验数据工程读者。需注意这是 Greptime 官方博客的客户访谈，缺少独立压测与迁移后量化结果，引用其结论时应结合自身负载验证。
文章介绍 vLLM 新增的 TorchTPU 后端，目标是在 Google Cloud TPU 上复用 vLLM 现有模型代码、CLI、OpenAI 兼容服务、调度器和 KV cache 管理。它作为平台插件接入，模型经 torch.compile 降为 XLA，TPU 专用优化集中在 JAX/Pallas 自定义算子。文中说明六种并行维度、MoE 常用的 DP+EP 组合、基于 TPU Sync 的零拷贝 KV cache offload 与分离式 prefill/decode 服务，并覆盖投机解码和前缀缓存。支持 Qwen、DeepSeek、Kimi、GLM、Llama、GPT-OSS、Gemma 等模型，推荐 TPU v7x，v6e/v5e/v5p 仍属实验性；文章偏官方发布说明，缺少独立基准与失败案例分析。
推荐收录：文章虽无独立基准，但明确给出了 vLLM TorchTPU 的插件接入方式、XLA/Pallas 内核分工、六种并行维度与 KV cache 卸载/分离式服务设计，能帮助读者理解 TPU 推理后端的系统边界。适合做 LLM 推理平台、异构硬件适配和分布式服务的工程读者参考，其“复用上游调度与缓存、在底层替换设备内核”的分层思路可迁移到其他加速器后端。主要风险是内容来自官方发布，性能和兼容性结论需结合 CI 与实测复核。
文章复盘 Meta 在 2026 世界杯期间应对全球流量峰值的工程实践。WhatsApp 峰值超 3000 万条消息/秒，决赛五分钟内投递约 84 亿条；流量高峰主要出现在中场、补水、终场和颁奖等中断时段，而非比赛本身。基础设施侧依靠 Taiji、Katran、Proxygen、全局负载均衡与 AutoScaling 分层吸收，Instagram 使用预留容量缓冲、国家级优雅降级、级联阻断和早期预警。WhatsApp 对 100 多个服务压测扩容，并因各区域同时达峰而放弃跨区借容量，也未冻结发布。结论是这些做法可沉淀为 2028 奥运会等大型活动的运行手册，但方案依赖 Meta 内部系统与容量数据，迁移需按自身规模验证。
推荐收录：文章给出真实大规模事件运维的一手证据，包括 WhatsApp 五分钟 84 亿消息、Instagram 预留缓冲、国家级降级、级联阻断、早期预警以及不跨区借容量、不冻结发布等关键取舍。适合 SRE、基础设施和高并发系统读者，可迁移为容量规划、降级策略与大型活动保障清单；但具体阈值和内部系统依赖较强，需结合自身规模验证。
本文复盘 Netflix 为支撑直播广告而重构 Ads Event Publisher。旧架构在投放关键路径同步写入全局 Metadata Registry，数千万并发下形成扩展瓶颈、强依赖和新鲜度风险。新架构让广告服务器仅将响应写入 Kafka，由 Flink 有状态作业在 60 分钟窗口内将客户端事件与服务响应按 key 实时 join，完成跨区域重路由、去重和发布；迟到事件由 Spark 批作业从数仓回补。去重采用稳定哈希 ID 和本地状态，保证至少一次与尽力去重，而非精确一次。上线采用双管道并行、共享富化模块、自动审计和按稳定 key 灰度切流，最终下线旧服务与 Registry。边界是依赖 Netflix Flink/Maestro 平台，且跨区域、重启或迟到恢复仍可能产生少量重复。
推荐收录：文章用直播广告的真实约束，完整展示了以 Kafka+Flink 流式 join 替代关键路径数据库写入的架构取舍、去重语义、跨区域路由、迟到回补和双跑灰度上线方法，并给出吞吐与一致性验证证据。适合流处理、实时数据管道、广告/计费和高可用系统工程师阅读，可迁移到降低关键路径依赖、以事件路由替代全局复制的场景；主要风险是与 Netflix 自研 Flink/Maestro 平台耦合较深，不能直接照搬。
文章回顾 Netflix Conductor 停止开源维护后的内部演进：该微服务编排引擎目前月执行约 4.2 亿个工作流，支撑媒体制作、广告和游戏等约 20 万工作流定义。作者按 1.0 到 4.0 梳理数据面重构，包括 Cassandra 取代 Dynomite、Timestone 取代 DynoQueues、Kafka 异步索引和 Iceberg 长期存储；4.0 通过分离工作流元数据与任务数据、引入 pending/terminal 分区解决宽行与竞态问题，使单工作流任务上限从 2500 提升到 30000，p99 评估延迟降低约 40%。文章还介绍异步评估消除锁竞争、Run Strategies 并发控制、Titus/Stratum 托管任务、按队列深度动态分配线程，以及类型安全 Java Workflow SDK。部分实现依赖 Netflix 内部平台，但架构取舍、尾延迟治理和工作流抽象方法具有可迁移性。
推荐收录。文章以真实生产数据说明 Conductor 在月执行 4.2 亿工作流后重构数据面与评估引擎，给出 Cassandra/Timestone 替换、pending/terminal 分区淘汰 LWT、异步评估降低 p99 锁竞争、按队列深度动态分配线程等工程证据。适合分布式系统、平台工程和工作流编排读者；尾延迟治理、并发控制和类型安全 DSL 设计可迁移，但 Titus/Stratum/Cosmos 等细节绑定 Netflix 内部平台。
文章复盘 Netflix 会员会话化 Spark 流水线升级中大规模 OOM、shuffle 溢出与阶段重试的工程案例。因小样本无法复现问题，作者根因定位到数据倾斜与长尾会话，并利用 Dataflow 分支名实现实验隔离，在同一时间窗并行运行多个全量实验。借助 AI Agent 与 tmux 自动化部署、轮询、对比与恢复，把多日串行调试压缩为一天内多轮实验。技术层面定位到 collect_list 按事件袋缓冲、Option 装箱和冗余字符串导致内存膨胀，通过去装箱、精简事件袋、Window 前截断及将 AQE 运行时广播阈值降至 10MB，使峰值内存从 112% 槽位降至 58%。文章还记录“变窄反而更快 OOM”与广播连接累积占约 3.1GB 等反直觉发现，并指出调优只能买时间，事件袋无界增长时架构必须改变。
推荐收录。文章以真实生产 OOM 为起点，完整呈现了从“小样本无法复现”到分支隔离并行全量实验、用 AI Agent 自动化操作，再到 collect_list/Option 装箱/AQE 广播阈值等根因定位与修复的工程闭环。对大数据平台、Spark 性能优化和 AI 辅助运维读者，其中“一次实验只改一个变量”“关注单行宽度与累积广播内存”等经验可直接迁移；局限是流程依赖 Netflix 内部 Dataflow/Maestro 环境。
文章复盘 GitHub star 历史 API 的重构：原 stargazers 接口按页返回用户身份和时间戳，既让公开列表被爬取用于垃圾信息或钓鱼，又让高星仓库查询昂贵；react/react 约 25.1 万 star 需约 2511 次请求，且分页 bug 每次请求还会统计全部 star，慢查询平均近 3 秒并被数据库终止。作者先限制 stargazer 与 watcher 列表权限，再确认维护者真正需要的是趋势曲线而非身份。评估保留事件但不返回身份、先聚合再分页后，发现 LIMIT/OFFSET 并不能减少分组排序成本。最终上线按日历周分页、先用索引 created_at 过滤再聚合为每日计数的接口，一次最多返回 30 周，react/react 降至约 24 次请求。文章也指出异常密集周、日历边界和取消 star 仍影响结果，并总结更小响应不等于更便宜查询。
推荐收录。文章直面真实的隐私与数据库性能冲突，完整呈现了从权限收紧、需求澄清、方案对比到 SQL 执行顺序优化的工程决策链，并给出可验证的请求数与慢查询数据。对设计公共 API、优化分页聚合查询或处理用户数据暴露风险的工程师和平台团队有较高迁移价值；其局限是特定于 GitHub 数据模型，密集周问题未完全解决。
文章深入介绍 Cloudflare D1 控制面如何扩展到数百万数据库：每个数据库由一个 SQLite Durable Object 支撑，核心原则是把查询热路径与中心 Postgres 解耦，通过 Workers KV 缓存路由元数据，并在缺失时回退到 Hyperdrive/Postgres 只读副本。创建和删除采用唯一 ID、重试幂等与 Postgres 创建检查点，Durable Object 定期心跳以最终一致方式自校正状态。查询经 Edge API、Eyeball Worker 转发到 Durable Object，避免中心单区域瓶颈。用量限额则用队列批处理、预聚合表、Hyperdrive 缓存和 ClickHouse/Quicksilver 异步执行。作者也指出这些流程依赖最终一致性，限额反应会略有延迟，路由与缓存设计需按平台组件边界权衡。
推荐收录。文章以 D1 扩展到数百万数据库为真实工程案例，明确给出控制面/数据面分离、Workers KV 路由缓存、Hyperdrive 回退、心跳自校正、队列预聚合与 ClickHouse 限流等架构取舍和失败恢复细节。对做多租户 SaaS、Serverless 数据库、平台控制面或高并发查询系统的读者，可迁移其幂等、最终一致性和缓存分层模式；主要限制是强依赖 Cloudflare 特定组件。
文章复盘 Cloudflare 数据管道在流量指数增长下控制硬件成本的多阶段改造。2022 年拆分单体消息 schema，2024 年将压缩算法从 LZ4 换成 zstd。2026 年引入跨区域共享接收池与延迟复制、在 Logfwdr 提前采样，并在管道各阶段做局部聚合。核心思路是把复制、采样和聚合尽量前移或下移，减少广域网与集中式数据中心处理量。结果上负载均衡约省 38 GB/s、采样约省 25 GB/s、聚合已省 7+ GB/s，合计约 70 GB/s，并降低约 50% 的接收端 CPU/内存；但采样会引入近似估计，聚合只适合可预定义维度和指标的数据集，且方案依赖其自研 Buftee、ClickHouse 与业务采样键。
推荐收录，因为文章给出了真实生产管道在 20 亿事件/秒规模下的多阶段优化证据，包含 schema 拆分、zstd 压缩、跨区域复制、采样和聚合的量化收益与取舍。适合数据平台、可观测性和大规模流处理工程师阅读，可迁移到日志/分析管道的降本、跨区域容灾和资源规划；需注意其效果依赖 Cloudflare 自研组件、ClickHouse 和业务采样键，不能简单照搬。
文章介绍 Meta 在 OCP Summit 2026 发布的开放 AI 网络基础设施，覆盖 scale-up、scale-out 和 scale-across。核心包括液冷网络机架 IcePack、102.4T IceCube 交换机、八平面 Flattened Planar Fabric、开源 RDMA 传输 MetaRoCE，以及跨区域 petabit 级 BAG 和基于 FBOSS/SAI 的 SRv6 骨干。scale-up 侧以 Tahan 以太网交换机支持 MTIA 300，并预览 102.4T 硅上 72 加速器/机架与 ESUN 规范演进。文章还讨论多云标准化、长距链路缓冲、降级路径负载均衡和 OSPA 交换机平台架构等工程取舍，但缺少实验数据和长期运维验证，偏向开放生态公告。
推荐收录：文章虽带 OCP 发布性质，但给出了 102.4T 液冷交换、FPF 多平面、BAG、MetaRoCE 和 ESUN 等具体架构与工程约束，并讨论多云异构建网、长距缓冲和降级路径负载均衡等可迁移问题。适合 AI 基础设施与数据中心网络工程师参考，可帮助理解超大规模 AI 集群在带宽、散热、可靠性和开放标准间的取舍；主要不足是缺少实测性能与长期运维数据。
文章介绍 Meta 如何把推理集群中局部闲置、可随时回收的 opportunistic capacity 汇聚成共享池，在不影响基线广告服务的前提下提升推荐质量。系统利用 Ads 推理的高弹性和自包含特征，设计两个互补杠杆：Rank More Ads 动态增加排序候选数量，需 CPU 与加速器余量；Serve Better Models 动态提高更强模型覆盖比例，主要消耗加速器余量。为安全消费波动容量，文章采用物理/逻辑隔离、RMA 延迟反馈 PID 控制、SBM 价值感知路由，以及服务端与客户端毫秒级 value-aware load shedding。核心结论是可选项随容量扩张收缩，基线延迟与可靠性受保护；边界是依赖特定负载结构，未来需扩展弹性范围、跨区域硬件可迁移性和自动容量分配。
推荐收录：文章给出 Meta 在大规模推理 fleet 中真实落地的容量池化方案，包括 RMA/SBM 对 CPU 与加速器的不同消耗、隔离与反馈控制、价值感知丢载等直接证据。适合推荐系统、推理平台、容量调度和 SRE 稳定性工程读者，其机会容量复用与优雅降级方法可迁移到其他高并发 ML 服务。
文章从青铜时代的漏水钟讲到现代软件，梳理漏桶（leaky bucket）作为准入控制（admission control）机制的由来与实现。作者区分漏桶在软件中的两种用途：作为计量器即时决定工作是否放行，作为队列决定可等待的工作量，并给出惰性排空公式，说明实现上只需保存上次水位与时间戳，开销极低。文中以 Shopify GraphQL Admin API 的文档化限流为例，说明按查询预估成本扣费、执行后多退少补、响应中回传桶状态让调用方提前降速的设计。随后对比 Oracle（1999）、SQL Server（2008）的资源管理器与 Postgres 的 statement_timeout，指出开源数据库缺少事前拒绝能力，并介绍 PlanetScale Database Traffic Control 以 token bucket、server share、burst limit、单查询上限和最大并发 worker 在查询执行前做准入决策。后半部分带有明显产品推广性质，读者需区分通用机制与厂商方案。
推荐收录：文章把漏桶的历史渊源、惰性排空的实现公式、Shopify 按查询成本计费的限流设计，以及 Oracle/SQL Server/Postgres 在准入控制能力上的差异串成一条可迁移的机制脉络，适合后端、数据库与 API 设计读者理解限流与资源预算的取舍。主要风险是后半部分对 PlanetScale Traffic Control 的介绍带产品推广色彩，读者应把通用机制与厂商实现分开评估。
文章介绍 GitHub 为应对 agent 规模化开发而重构 Git 基础设施的背景与设计原则。随着 agent 并发提交，GitHub 月事件量从约 2182 亿增至 4733 亿，push 同比增长 4.9 倍，9 月提交量达 73.8 亿次。现有 Spokes 架构把仓库完整副本存于多台 fileserver 本地盘，用三阶段提交保证一致性，却把持久化与扩容绑定，导致增加读副本反而拖慢写入，写入受最慢副本制约。新架构以最小化协调、拆分存储与计算为核心：只让引用更新参与协调，把压缩和 GC 移出服务路径，权威数据下沉到 Azure Blob Storage，读容量由缓存 worker 弹性提供，从而独立扩展读写并更快从故障恢复。内部基准显示写吞吐最高提升 35 倍，但文章偏高层设计，具体实现细节留待后续。
推荐收录，因为文章给出了真实规模数据与明确的架构取舍：指出多副本本地盘把持久化与读扩展耦合、写入受最慢副本制约这一根因，并用 35 倍写吞吐基准佐证。适合从事分布式存储、平台架构或大规模版本控制系统的读者，其最小化协调、存储与计算解耦、维护移出服务路径的思路可迁移到高写入并发系统设计。
LinkedIn将ClickHouse从分布式追踪扩展到指标元数据发现与分析。追踪系统每天约0.8万亿span和200TB数据，在三数据中心、每集群22分片部署，通过列排序和重分区将查询优化到2秒内。随后团队把超130亿指标、30%日更替的遗留RRD元数据从三个独立服务迁移到单一ClickHouse集群，用ReplacingMergeTree去重、变更捕获和别名切换实现透明迁移，并用投影支撑重聚合。新系统每分钟服务15万+查询，平均延迟68ms，内存和计算分别降至约1/5和2/3，且有余量翻倍指标量。该案例技术细节具体，但来自ClickHouse官方博客，且单分片设计和大规模迁移的后续演进未充分展开。
推荐收录，因为该文给出LinkedIn超大规模使用ClickHouse的完整工程细节：追踪系统分片、red-black部署与查询优化，指标元数据迁移的ReplacingMergeTree去重、变更捕获、别名切换和投影设计，以及150k QPM/68ms、内存降至1/5等可验证结果。适合可观测性、大规模数据平台和OLAP选型的工程师参考，迁移策略和Schema设计可迁移。主要风险是官方博客可能有宣传倾向，且单分片扩容细节未展开。
文章以 PlanetScale 的 Neki 分片方案为背景，讨论多租户场景下的热分片问题：按 tenant_id 均匀分布租户在业务增长后会失效，出现超大租户压垮单个分片、跨租户查询增多等情况，即租户均匀不等于数据均匀。作者引用 Slack 使用 Vitess 的真实案例，说明 messages 表从按 workspace 分片改为按 channel 分片后，把常用的单分片查询保持在一起、把跨分片查询限制在批量或管理路径，从而降低热点并获得 CPU 与存储余量。文中给出三级处置路径：纵向扩容、按 key range 隔离大租户，以及最终按访问模式和查询形状重新分片部分表，并说明 Neki 用声明式 data topology 与在线 Reshard 在不停机的情况下迁移数据。边界在于内容带有产品宣传色彩，缺少性能基准和失败案例，Postgres 与 MySQL 的表述也略有出入，读者需结合自身系统验证。
推荐收录：文章把热分片的成因与三类处置路径（扩容、按 key range 隔离大租户、按访问模式重分片）讲得具体，并给出 Slack/Vitess 的迁移决策依据与 key range 配置示例，可迁移到多租户 SaaS 的分片键复审。适合负责分库分表、租户隔离与在线扩容的工程师和架构师；但结论围绕厂商产品，缺少量化基准，引用前需自行压测验证。
文章以 Salesforce Cloud Atlas 身份数据存储为例，讨论 Tier-0 身份服务在流量突增和上游重试下如何演变为级联故障。团队原有每实例限流在自动扩缩容和多租户场景中暴露阈值失真、全局容量不可见和 noisy neighbor 问题。重构方案包含基于队列时延提前感知压力、优先削减低优先级请求的智能负载卸载，以及无中心协调器的全局配额管理，由各服务器共享客户用量并独立限流。文章据此总结保护服务而非单机、先观测后执行、优雅降级、简化配置、纵深防御和可逆发布等原则。局限是问答形式偏高层，缺少具体算法、参数、实验数据和故障演练细节，读者难以直接复现，但架构权衡和原则仍有迁移价值。
推荐收录。文章直接呈现 Tier-0 身份平台从每实例限流到智能负载卸载与无协调器全局配额的工程演进，并给出队列时延、优先降级、多租户公平和纵深防御等可迁移取舍。适合 SRE、分布式系统与高可用平台工程师阅读，用于设计限流、过载保护和级联故障防护。局限是未展开算法与实验数据，需结合团队实际验证。
Meta 开源了内部使用九年多的通用指派问题求解库 Rebalancer，并配套 OSDI'24 论文。文章把指派问题抽象为对象、箱子、约束与目标，核心设计是解耦问题描述与求解过程：先用维度、分区、作用域、利用率等建模原语刻画现实策略，再通过表达式 API 与高层 spec API 表达约束和目标，最终编译成表达式图 DAG。求解提供两条路径：最优解器把图翻译成 MIP，靠变量聚合、可互换性与对称性破缺压缩模型，最坏规模为 O(|objects|*|bins|)；局部搜索解器直接在图上游走，邻域最坏 O(|objects|+|bins|)，可并行、每秒数百万次评估并支持剪枝。文中给出生产数据（每日约 4000 万次求解、30 多种问题形式、P99 12 秒）以及调试用 Web UI Rebalancer Explorer，并以 Apache 2.0 开源。
推荐收录：文章提供了可复用的优化系统设计证据——描述与求解解耦的建模原语、表达式图，以及 MIP 与局部搜索两条路径的复杂度、规模上限和选型建议，还有每日 4000 万次求解、P99 12 秒等生产数据与 OSDI'24 论文支撑。适合从事资源调度、容量规划、负载均衡和组合优化落地的工程与算法读者，其中“先用最优解器原型、再迁移到局部搜索”的经验可直接迁移。
Meta 介绍规划中的跨洋海缆 Petal：连接法国与美国约 7000 公里，目标 2029 年投运，实现 1 Pbps 容量，成为首个皮比特级跨洋系统。其核心是采用 2-core fiber，在 24 光纤对中达到等效 48 对的空分复用容量，并通过超纯石英、折射率控制和反向传输来降低衰减与串扰。中继器使用 96 芯单体内放大和 FIFO 将双芯转换为单芯再恢复，结合泵浦共享把功耗控制在 18 kV 供电限制内。文章还梳理从 Marea、Amitié、Anjana 到 Petal 的容量演进及 NEC、住友电工、Orange 的分工。不足是公告性强，缺少独立测试、成本和长期运维数据。
推荐收录。文章虽带有 Meta 基础设施发布色彩，但给出了 Petal 的容量目标、2-core fiber 与 24 对光纤等效 48 对的 SDM 设计、FIFO 中继器、96 芯放大和 18 kV 供电边界等具体工程约束。适合网络基础设施、光通信与海缆系统读者参考，其容量扩展路径和功耗/工艺取舍可迁移到大规模互联系统评估。
文章介绍 Elastic Cloud Serverless 上用跨项目搜索（CPS）实现集中式 SOC 告警分诊。作者把 1 个源项目连接 100 个关联项目，在源项目运行约 2100 条预置检测规则，验证检测、分诊、调查与响应全流程。结论是该集中模型在规模下可行：规则和告警集中在源项目，数据仍留在各项目，分析人员用统一队列查看跨项目上下文。文章给出 ES|QL 查询模式、告警按项目汇总和列投影等性能建议，指出成本主要取决于单项目数据量与查询形态，而非关联项目数量。同时列出边界：响应动作、关联项目自生告警、Attack Discovery 等不跨项目聚合，需坚持“集中分诊、本地响应”。适用于多团队/区域/客户需数据隔离但共享检测分诊的组织。
推荐收录：文章基于 1 个源项目连接 100 个关联项目、运行约 2100 条检测规则的真实压测，给出 ES|QL 查询模式、性能取舍和 CPS 能力边界表，属于可迁移的集中式安全运营工程经验。适合安全平台、SOC、云原生安全架构读者评估多租户检测与分诊方案；主要风险是功能强绑定 Elastic Serverless，落地时需核对响应动作不能跨项目等限制。
本文是 Oxide Omicron 控制面数据库的设计 RFD，围绕强一致性与可扩展性，给出多租户 API 资源（Project、Instance、VPC 等）的建模与查询模式。作者采用 UUID 主键、身份元数据、按父作用域与 name 的唯一部分索引，支持分页、重命名和软删除，并避免显式外键。文章用条件 UPDATE、CTE、generation number 与 rcgen 处理并发更新和检查-使用竞态，也比较事务、CTE、saga 的适用场景。最后分析读-改-写、长事务、双管理员并发及集合删除/创建竞态，并指出实现尚不完整、方案依赖 CockroachDB SERIALIZABLE 与具体 API 约束。
推荐收录。文章不是泛泛介绍数据库范式，而是给出可核验的表结构、唯一部分索引、条件 UPDATE/CTE、rcgen 和 saga 选择规则，并明确 CockroachDB SERIALIZABLE、软删除与双管理员并发下的边界。适合控制面、分布式数据库和后端架构读者，其中的并发控制与一致性模式可迁移到多租户 API 设计；风险是方案与 Oxide/CockroachDB 强耦合且实现未完成。
该 RFD 界定 Oxide 控制平面持久化数据存储需求：需存储实例、虚拟磁盘、网络资源、服务器、用户/SSH 密钥等对象，支持持久 CRUD、分页一致性枚举和乐观并发控制，并讨论 ACID 是否必需。非功能要求包括强一致、有限故障下可读写、零计划停机、无人值守、可诊断、安全、开源与低成本，且把逻辑复制和在线 schema 迁移列为一等能力。文中估算单机架约万级实例、约 100 GiB 数据，外部 API 延迟需数百毫秒内、数据库访问约 150ms 内，短生命周期负载可达千级 rps；作者据此主张先评估现有系统，并给出从调研、Jepsen 失败分析到部署、故障与长时压测的漏斗式选型方法。候选聚焦 CockroachDB、Yugabyte、TiKV/TiDB、VoltDB 等 NewSQL，排除传统 RDBMS、NoSQL、FoundationDB 与 ZooKeeper/Etcd 类系统；但该文仍是早期需求框架，未给出最终基准和选型结果。
推荐收录。该文不是产品宣传，而是把控制平面数据存储的功能/非功能需求、规模与延迟估算、自研与采购取舍、候选 NewSQL 及排除项、以及分阶段评估方法写得很具体，对设计高可用控制平面、做分布式数据库选型或需要向团队说明存储约束的工程师有直接参考价值。局限是它属于早期 RFD，未给出实测基准和最终选型，读者应把它当作需求清单和评估框架而非结论。
RFD 70 提出多租户基础设施中容量、分配与利用率的管理框架，先区分 in-use、provisioned、reserved、capacity，并定义 utilization、threshold、overprovisioning、bursting。其核心原则是用透明、可操作的数据帮助用户和运维决策：展示容量仪表盘与按用户/团队/项目下钻视图，设置阈值告警，提供一键调整实例或磁盘、通知项目成员的流程，并用配额防止过度分配。文档明确反对超售，强调扩容与缩容并重、按实际使用率优化，并建议将利用率与成本节省纳入账单，甚至用排行榜激励良好使用习惯。它属于早期设计讨论稿，给出术语、原则、指标和交互场景，但缺少实现细节、规模化验证和预测模型的量化评估。适用于云平台、SRE 与基础设施容量治理场景。
推荐收录：它把容量治理从“看监控”推进到可操作流程，明确区分 in-use、provisioned、reserved、capacity，并给出仪表盘、阈值告警、配额、扩缩容和账单联动等机制。对云平台、SRE 和基础设施团队，反对超售、以利用率驱动资源调整的原则可直接迁移到多租户容量规划。风险是它仍是 RFD 设计稿，缺少落地数据与实现验证，部分激励机制需按组织裁剪。
Kubernetes v1.37 引入调度器抢占以支持就地 Pod 资源调整（Alpha）。此前运行中 Pod 申请扩容若超出节点余量，Kubelet 会将其标记为 Deferred 并无限等待；新特性让调度器跟踪此类 Pod，并在其所在节点上抢占低优先级 Pod 释放容量，使高优先级应用的扩容得以完成。抢占严格限于同一节点，扩容资源被视为已消费以避免重复分配，且决策统一交由调度器以遵循全局优先级、PDB 与优雅终止策略，并支持节点级关闭。文章含 kind 集群验证示例，但该特性仍为 Alpha，要求 v1.37+ 且全组件启用门控，若无合适抢占对象则扩容仍保持 Deferred。
推荐收录：文章来自 Kubernetes 官方博客，系统解释了 v1.37 就地 Pod 扩缩容的调度器抢占机制，包括 Deferred 状态处理、同节点抢占边界、资源预留和与 Kubelet 的职责分离，并给出可复现的 kind 验证步骤和节点级关闭配置。适合平台工程师、SRE 和集群运维人员评估在资源高利用率场景下如何安全使用就地扩缩容；其架构权衡与验证方法可迁移到其他调度策略设计。需注意该特性仍为 Alpha，且要求 v1.37+ 全组件启用门控，后续版本可能调整。
ZGateway 是 Meta 为 ZippyDB 键值存储新增的无状态代理层，目的是改变超百万客户端直接连数据库产生的稠密连接网格及其可靠性风险。它把客户端与后端收敛成两跳，使连接扇入扇出规模由代理层可控，并通过跨客户端批处理和合并降低 RPC 开销、缓解热键冲撞。代理层同时承载租户级准入控制、按 CPU 自适应的负载均衡、带实时失效的读缓存，以及可配置的跨区域容灾；迁移采用分服务、分前缀的百分比开关实现可逆灰度。文章给出的实测边界是：ZGateway 承载约 40% ZippyDB 流量、平均约 6% 计算开销，压测中丢弃只作用于少数噪声租户，其他租户成功率保持 99.9%。最后作者展望了多进程隔离、控制面外置与 AI 辅助调优等方向。
本文来自 Meta 生产环境的系统级工程复盘并包含明确数据和机制，不只是架构简介。它展示了一个代理层如何同时解决连接管理、高可用、租户隔离与流量治理，适合关注分布式系统、基础架构和可靠性设计的读者。文中的扇入扇出建模、灰度迁移和自适应负载均衡思路可以迁移到其他大规模代理或网关场景，但需注意 Meta 内部基础设施的耦合与规模化条件。
文章介绍 Kubernetes v1.37 中 HorizontalPodAutoscaler（HPA）支持将工作负载缩容到零副本的 Beta 特性。作者首先解释了为什么缩零必须使用 object 或 external metric，因为 CPU/内存这类资源指标来自运行中的 Pod，副本为零时无法提供扩容信号；而队列长度等外部指标可以在无 Pod 时继续读取。随后给出了基于 Prometheus external metric 的配置示例，包括 metrics adapter 规则、验证指标可用性的 kubectl 命令以及 HPA 清单。文章重点说明了 ScaledToZero 状态条件如何区分控制器自动缩零与运维人员手动暂停，并列出升级、回滚或禁用特性时的注意事项。最后讨论了冷启动延迟和适用场景：该特性最适合队列消费者、批处理等可容忍延迟的工作负载，而 HTTP 请求型负载需要额外的缓冲层。
本文是 Kubernetes 官方博客对 HPA 缩零 Beta 特性的权威说明，不仅包含配置示例，还深入解释了对象/外部指标的必要性、ScaledToZero 条件设计以及版本升级时的风险控制，信息密度高且可长期参考。适合平台工程师、SRE 和云原生应用开发者阅读，可直接指导基于队列的弹性伸缩部署。
文章深入解析了 PlanetScale 的 Neki 路由器在分片 PostgreSQL 数据库中的核心作用与实现机制。它指出分片数据库的难点在于决定查询应路由到哪些分片，Neki 为此引入了双层计划：先由路由器基于数据拓扑生成 Neki 计划，再将改写后的 SQL 交给各分片上的 PostgreSQL 生成传统执行计划。文章通过单点路由和 scatter-gather 两个具体示例，展示了路由器如何识别分片键、绑定参数、推送 limit、汇总多分片结果，并利用侧车进程通过 gRPC 转发工作。同时说明了路由器无状态、可独立扩展的特点，以及与 PgBouncer 等连接池工具的差异。文章还点明了 Neki 的两个缩放维度：分片扩展数据和 PostgreSQL 引擎，路由集群扩展分布式查询处理与连接管理。整体对理解分布式数据库查询路由与分片架构具有很好的参考价值。
推荐收录。文章不是抽象的理论介绍，而是直接展示 Neki 路由器的双层计划、分片路由和 scatter-gather 的具体实现，包含 EXPLAIN 输出和架构组件说明，证据具体。适合数据库内核工程师、分片库用户及分布式系统架构师阅读；其中关于无状态路由器、连接处理与查询处理分离的设计思路，可迁移到其他分布式数据库或网关类系统。
本文是 ClickHouse 团队对 Mat Duggan、Charity Majors 提出的“ClickHouse 正在赢得可观测性战争”观点的回应与剖析，明确“胜利”仅限定在存储与查询层。文章解释列式架构为何契合可观测性数据：按列存储与排序键利于压缩编码，稀疏主索引与跳数索引减少 I/O，向量化执行、SIMD 与跨分片并行加速聚合，并缓解高基数问题。还讨论了全文检索倒排索引、单库承载日志/追踪/部分指标、SQL 表达力与 Apache 2.0 许可带来的采纳优势。作者也坦承边界：Prometheus 式指标的 PromQL 兼容仍是最大缺口，TimeSeries 引擎与 API 尚不稳定，数据库本身不等于好的可观测性产品，小团队或自建引擎的厂商未必适用，并指出 Agent 工作负载带来低延迟、高并发与全保真留存的新要求。
推荐收录。文章虽出自厂商博客，但系统梳理了列式存储契合可观测性数据的机制——压缩、索引裁剪、向量化、并行聚合与高基数处理，并较诚实地指出 PromQL 兼容、ordering key 与 schema 设计等边界，适合负责可观测性平台或日志/追踪存储选型的工程师参考。其架构权衡与“何时不适用”的判断有可迁移价值，但读者需注意其自证立场与客户证言带来的偏向。
ClickHouse 团队复盘内部可观测性平台 LogHouse 的 OpenTelemetry 摄取管道三次演进。第一版 agent+gateway 架构在 5000 万 events/s 规模下无法承受 ClickHouse 反压而频繁 OOM；第二版启用 collector 本地 WAL，需改造成 StatefulSet，1TiB 积压约需 4 小时排空，且 FIFO 顺序阻塞最新数据，只能截断 WAL 丢数据。团队放弃引入 Kafka，改用基于 S3 的优先级故障转移：仅在 ClickHouse 反压时由 failover connector 溢出到对象存储，再通过 SQS 事件通知由独立 catchup collector 回灌，规避常态 PUT 成本。文中给出完整 collector 配置与一小时停机 gameday 验证结果，也指出恢复期无法定位具体缺失数据、新区域需额外基础设施等局限。
推荐收录：文章完整呈现从默认两层采集架构到自研 S3 溢出方案的取舍链条，给出 5000 万 events/s、1TiB 积压需 4 小时排空、每年 10-50 万美元 PUT 成本等具体数字，并用一小时停机 gameday 验证无数据丢失。对负责可观测性采集、高吞吐数据管道或 ClickHouse/OTel 落地的工程师，其 failover connector 的队列开关顺序、优先级路由和 catchup 回灌设计可直接迁移。
文章围绕 Postgres 大表引发的工程问题展开，先从真实案例说明级联删除导致 WAL 放大、网络饱和和副本延迟，最终演变为业务中断。随后系统剖析大表在 autovacuum 启动阈值过高与执行缓慢、空间回收失败与 bloat、长查询占用连接、备份与恢复变慢、索引膨胀以及宽行 TOAST 的 OID 限制等方面的详细机制。作者对比分区、垂直扩展和分片三种解决方案的适用边界，指出分区能细分堆并改善 vacuum，垂直扩展仅能临时缓解，而分片可将大数据表拆到独立集群，避免单集群的全局性限制。文章也提醒分区不能解决 xmin 的集群级快照钉扎，分片需要选好 shard key。适合需要设计高可扩展数据库架构的工程师参考，但结尾对自有产品 Neki 的推广属于商业内容。
本文不是泛泛的问题清单，而是通过真实故障案例和具体参数（如 autovacuum 阈值、32 位 XID、TOAST OID）揭示大表问题的本质，对分区、垂直扩展和分片做了清晰的权衡对比。适合数据库管理员、SRE 和高并发应用后端工程师，文中诊断大表问题的框架和解决方案取舍可以迁移到自有系统中。注意文章末尾有产品推广，但技术分析独立完整，是长期有效的参考资料。
Meta发布自研RDMA传输协议MetaRoCE，面向AI规模GPU集群，运行于普通以太网，并计划通过OCP开放规范、参考实现和一致性测试套件。其核心是将网络智能从交换机移向NIC，支持原生乱序投递、逐路径喷发、免PFC的丢失容忍传输，以及发送端AIMD与接收端速率提示的拥塞控制。在64节点AMD GPU集群测试中，相比RoCEv2，MetaRoCE在all-reduce和all-to-all上吞吐更高、流完成时间更低，1%丢包时保持约86%吞吐，多平面扩展近线性，平面故障可自动恢复。现有RDMA Verbs应用无需修改即可使用，文章也承认在机内、跨数据中心和存储/KV缓存等场景仍需后续优化。
推荐收录。文章来自Meta工程博客，详细阐述了MetaRoCE的动机、设计权衡和实测数据，包括与RoCEv2的对比、损失下的优雅降级和多平面弹性，证据链完整。适合网络协议开发者、AI基础设施架构师和分布式系统工程师参考，其端点智能、逐路径拥塞控制等思路可迁移到其他高性能网络设计。需要注意文章同时是产品发布稿，基准规模和场景有限，实际部署效果需独立验证。
文章回顾了Postgres分片技术二十年来的演进。作者先从“shard”一词在Ultima Online游戏中的起源讲起，说明MySQL因LAMP生态先行形成了Vitess等成熟方案，而Postgres则长期依赖各公司自建。随后梳理了Skype的PL/Proxy、Instagram的逻辑分片、Citus扩展、PgDog代理、Aurora以及Spanner/CockroachDB/Yugabyte等Postgres兼容分布式数据库，逐一分析其架构与取舍。核心观点是显式分片比自动分片更可预测，原生Postgres集群比兼容层更可控。文章最后介绍PlanetScale推出的Neki，宣称结合历史经验提供显式分片、水平扩展路由器并托管备份恢复，但该部分带有明确的产品推广色彩。整体适合作为了解Postgres分片方案演进的入门综述，但对Neki的介绍需要以批判视角审视。
推荐收录，因为文章系统梳理了Postgres分片从PL/Proxy到Citus再到Spanner兼容方案的完整脉络，并给出了每个方案在运维复杂度、路由瓶颈、跨分片查询上的具体取舍，能帮助数据库团队在做分片决策时建立历史坐标系。适合数据库工程师、架构师阅读。需注意文章后半部分是PlanetScale自家产品Neki的推广，作为技术评述存在立场偏差，读者应区分事实与产品主张。
本文介绍 vLLM-Omni 的分布式逐层卸载（DLO），用于在多 NPU/GPU 上运行超出单卡 HBM 的 DiT 模型（如 64B/124GB Cosmos3-Super）。方案结合 meta device+mmap 加载、权重分片+AllGather 重建、双缓冲预取与计算重叠、DP 多并发。实测 Ascend 910B3 上冷启动 cgroup 峰值由 178GB 降至 47GB，主机内存从 O(dp×model) 降为 O(model+dp×常数)，4 并发吞吐达 HSDP 单请求的 3.3 倍；B300 上 DLO+AG DP4 吞吐为 HSDP+USP4 的 1.39 倍且 HBM 仅 30%。MiniMax-H3 表明 DLO 模式依赖拓扑：DP1×SP8 宜用 AllGather，DP8×SP1 宜用 rank-local。但 400GB 外推未实测，最大块尺寸、带宽与输出质量在该规模仍未验证。
推荐收录：文章给出可复现的系统级设计，四项技术分别对应明确的内存/吞吐瓶颈，并附 Ascend 与 B300 实测数据及失败边界。对从事大模型推理基础设施、显存受限模型部署和分布式并发的工程师有直接迁移价值；需注意 400GB 外推未实测，拓扑结论限于单节点单输入集，不能直接当作通用生产结论。
文章复盘LinkedIn消息系统从邮件式单体架构到全新架构的设计阶段。旧系统最初使用单一Oracle数据库和分片复制，消息量五年增长四倍后，产品向聊天体验演进但代码复杂度剧增，导致开发效率下降。作者提出产品与工程需求，特别强调迁移自定义业务逻辑需要近60个转换器，并决定将数据持久化拆分到多个服务以独立扩展，同时接受分布式事务代价。团队通过高层架构文档、设定设计原则和赋权技术负责人并行推进，制定正确性优先、构建正确、再求快等原则。文章还总结了迁移策略、异步处理、团队结构和项目组织方面的经验教训，但未深入具体实现细节。
推荐收录：这是LinkedIn真实消息系统重构的工程案例，包含从单体到分片再到新架构的演进、明确需求和设计原则，以及迁移与团队组织的教训。适合架构师、后端工程师和技术负责人参考大型系统重新设计、跨团队协作和数据迁移的可迁移方法。
本文介绍 LinkedIn 将身份服务中的 midtier 和 data service 两层合并为一个服务的实践。原架构中 data service 仅提供数据验证和 Espresso 存储访问，业务逻辑薄弱但维护成本高，且增加网络跳数。团队在保持对外 API 不变的前提下，先将 data service 的 REST API 作为本地库嵌入 midtier，随后通过 T-REX 框架逐步灰度、下线旧服务并清理技术债。性能测试使用 Dark Canary 复制生产流量对比，结果显示 p50、p90、p99 延迟分别降低 14%、6.9%、9.6%，内存分配率下降 28.6%。最终下线整个 data service 集群，节省超过 12000 核和 13000GB 内存。文章强调这是针对特定场景的权衡，并非所有微服务都应合并。
推荐收录，因为文章提供了完整的工程案例：从问题动机、架构决策、灰度实施到性能验证，数据详实。直接证据包括 p50/p90/p99 延迟改善、内存分配下降和资源节省。适合关注微服务粒度、性能优化和成本控制的架构师与后端工程师。可迁移价值在于展示了当数据服务逻辑薄弱时合并服务的考量方法，以及利用灰度发布和流量镜像降低高风险变更的实践。
文章介绍 LinkedIn 为替代 Kafka 而自研的可扩展日志存储系统 Northguard，以及其上的虚拟化发布订阅层 Xinfra。Northguard 通过分段、范围、主题的数据模型，基于 Raft 的动态分片元数据状态机（DS-RSM）和 SWIM 去中心化成员协议实现高可扩展性与可运维性。核心设计是以段为复制单元的日志条带化，自然均衡负载、避免资源倾斜，并论证范围模型相比固定分区能减少流处理中的 shuffle。评测对比显示 Northguard 在元数据可扩展性、集群数量、负载均衡、自愈、一致性和持久性上均优于 Kafka，且通过 Xinfra 虚拟化和双写实现了透明迁移。文章主要面向大规模日志存储和分布式系统工程，技术细节以高层设计为主，缺少底层实现参数和故障恢复的深入展开。
本文来自 LinkedIn 真实生产环境，规模达 32T 记录/天、17PB/天，详细展示了从 Kafka 迁移到自研系统的完整工程决策与权衡，包括数据模型、复制单元选择、元数据分片和虚拟化迁移。适合分布式存储、基础设施和架构师参考，尤其关注日志存储、自动负载均衡和大规模系统演进。其可迁移价值在于以细粒度分段替代整日志复制来改善可运维性和可用性的思路，但读者需注意文章未公开具体实现代码和完整故障处理细节。
文章介绍了 LinkedIn 开源的新组件 iris-message-processor，用于替换原有 Iris 事件管理系统中单 leader 的 Python 子进程 iris-sender。旧架构串行处理消息、依赖 Galera 强一致数据库作为消息队列，在高负载下出现延迟激增和复制死锁。新服务用 Go 编写，采用分布式 bucket 动态分配，节点可水平扩展，数据库不再充当队列。压测显示高负载下性能提升约 86 倍，6000 条突发消息处理时间从近 30 分钟降至 10 秒内，节点失效后 30 秒内自动重平衡。该组件已生产运行一年无中断，并与现有 Iris-api 保持兼容，支持渐进式切换。
推荐收录，因为文章提供了从单点瓶颈到分布式架构的完整演进案例，包含明确的问题定位、设计取舍、压测数据和生产验证。对负责高吞吐消息处理、事件驱动系统或 on-call 基础设施的工程师有直接参考价值，特别是水平扩展、去数据库队列和渐进式上线策略可迁移到类似场景。
文章复盘了LinkedIn My Network页面加载缓慢和内容跳动的问题，旧架构中移动端与Web端并行请求多个API，独立渲染不同推荐区块，导致首屏等待近两秒并出现UI闪烁。作者团队将多端点统一为单一API并引入分页，把无限滚动的PYMK拆成多个小cohort，预构建后放入缓存，后续按页获取；同时采用渲染模型，由API定义通用banner和内容容器，减少客户端业务逻辑。优化后P90延迟下降43%，成本节省七位数，Web端LCP和FID显著改善，会员参与度提升。文章未深入讨论缓存一致性、失败处理和更复杂个性化场景，但提供了可工程迁移的架构权衡。
推荐收录，因为文章给出了完整的性能优化工程案例：从多端点并行到统一API、分页和预构建缓存，再通过渲染模型简化客户端，并用量化指标验证收益。适合后端、前端及系统设计工程师参考，其中缓存设计、API收敛和渲染模型解耦的思路可直接迁移到类似推荐流或内容聚合页面的优化中。
文章介绍了 LinkedIn 用 Rust 构建的通用检索引擎 FishDB，替换了运行近十年的 Java 系统 FollowFeed。文章首先分析了旧系统的局限：Java 对象内存开销大、GC 导致高尾延迟、数据模型僵化且业务逻辑耦合，限制了推荐系统的扩展和迭代。随后解释了选择 Rust 的原因，并通过对比实验展示 Rust 在内存效率上的显著优势。FishDB 采用 scatter-gather 架构和 lambda 架构，提供了灵活的命令式查询语言和多种索引结构，包括倒排索引、前向索引、引用索引和基于 RocksDB 的属性存储，以支持图状数据模型和高效过滤排序。迁移采用分层渐进方式，通过 JNI 桥接保持 API 不变，实现了零中断切换，最终取得 2 倍效率、减少 50% 硬件、p99 延迟 40ms 的成果，并将实验周期从数周缩短到数天。文章也指出当前查询语言仍为命令式，未来计划引入声明式语言和向量搜索。
本文是一份高度完整的工程案例，从问题诊断、技术选型、系统架构、索引设计到灰度迁移提供了详实细节和量化结果，展示了如何用内存安全的高性能语言重构大规模检索基础设施。适合负责推荐系统、搜索引擎、分布式存储或性能优化的工程师阅读，可迁移的经验包括内存数据结构设计、Rust 在服务端的应用模式、分层迁移策略以及如何平衡灵活性与性能。
本文复盘了LinkedIn职位摄取系统的设计，该系统每日处理数百万职位、超20TB原始数据。文章先梳理异构源、传输协议、安全、数据新鲜度等挑战，再介绍模块化事件驱动流水线和Job Intake、Job Processing Pipeline两大阶段。重点阐述Job Pull的orchestrator与专用Mining Node分离、抽取逻辑配置化、AI辅助Sitemap创建，以及基于START/JOB/END状态机的Mining Task和优先级队列。处理层通过静态/动态Job Field Processor和pre/mid/post三层实现清洗、增强与校验，并通过multiplexing生成衍生职位。文章以配置驱动扩展、上游背压和让用户掌控平台为关键经验，但偏高层架构，未深入具体实现与性能数据。
收录的直接证据在于文章展示了从异构数据摄取到标准化处理再到发布的全链路架构，包括orchestrator/worker分离、配置驱动抽取、优先级队列和动态处理器等可迁移设计。适合分布式系统、数据平台或集成工程师借鉴，尤其对需要快速接入多源数据、控制上游负载和将定制能力下放给非工程团队的系统有启发。风险是偏高层描述，缺少细粒度实现和量化验证，但整体技术深度满足长期参考要求。
本文介绍 LinkedIn 基于 cert-manager 构建的 Kubernetes 工作负载身份安全框架。系统通过 CSI 驱动将证书以只读卷挂载到容器，私钥仅存内存，并利用 Identity Registry 进行身份证明和签发，防止身份冒用。针对多集群和 25 万 Pod 规模，团队发现开源 approver-policy 无法满足 5 万并发 CertificateRequest 的 SLO（P95 60 秒），遂自研 lipki-controller 作为审批和签发器，并通过 API QPS/并发调优、分区 sharding 实现水平扩展。文章还介绍了 Kyverno 策略限制签发源、渐进式迁移和 Java/Go/Rust 认证库集成。测试显示 54K 请求审批与签发 P90 为 19.3 秒，但水平扩展目前仅用于容灾，尚未实现动态扩缩。
推荐收录。文章不是简单的工具介绍，而是完整展示了 LinkedIn 在超大规模 Kubernetes 集群中落地 cert-manager 的真实工程路径：从身份注册、CSI 挂载、Kyverno 策略到自研 lipki-controller，并给出 54K CertificateRequest 下 P90 19.3 秒的实测数据。适合负责容器平台安全、PKI/证书生命周期、服务网格 mTLS 或大规模 Kubernetes 运维的工程师借鉴，其控制器调优、分区 sharding 和渐进式迁移策略具有可迁移价值；主要边界是 LinkedIn 内部系统和规模假设，且水平扩展暂仅用于容灾。
文章介绍了LinkedIn Hiring Assistant中基于语义搜索的AI代理检索与排序系统MUSE。面对自然语言招聘查询与十亿级会员画像的匹配问题，团队构建了LLM-as-a-judge驱动的教师模型，生成海量资格匹配标签，训练双塔Transformer嵌入模型，并采用Matryoshka嵌入同时服务检索与排序。生产系统采用Lambda架构，结合批量重建与CDC增量推理，通过IVFPQ索引和优化管道实现亚秒级检索。离线回放与在线A/B测试表明，MUSE提升了候选相关性和招聘者参与度，但近似检索与后过滤的损失叠加仍是后续优化方向。
本文详细披露了LinkedIn大规模语义搜索系统的设计与实现，覆盖教师监督、双塔嵌入、十亿级向量检索和在线评估等关键环节，技术细节丰富且可验证。适合搜索推荐、AI基础设施和MLOps方向的工程师参考，其Matryoshka嵌入分层服务、CDC增量更新和IVFPQ优化等实践可直接迁移到类似规模系统。
文章介绍了LinkedIn在管理约5EB数据和100亿对象的HDFS集群时，如何通过重新设计块放置策略来加速维护操作。默认BPP在维护时会导致大量数据复制和网络拥塞，而采用升级域BPP并定义20个升级域，将同一机架节点归入同一升级域，可以消除维护时的数据复制需求。文章详细描述了对3+EB存量数据进行分批再分布的过程，以及发现开源升级域BPP的写性能问题并开发新BPP排除已选升级域节点的改进。最终实现了每天升级约4.5%节点，显著提升了可靠性和安全性。
推荐收录，因为文章提供了真实超大规模HDFS集群维护中的完整工程案例，包含问题定义、架构取舍、数据迁移方案和性能优化细节，证据充分。适合负责分布式存储、大规模基础设施或HDFS运维的读者参考，其中升级域划分、利用维护模式减少复制和分批迁移的策略可直接迁移到类似系统。
文章讨论云数仓资源管理中长期存在的矛盾：业务负载波动大，固定规格资源常按峰值锁定，导致平均利用率低；传统存算分离架构弹性慢，扩容伴随缓存预热和数据重分布，容易引发查询延迟抖动。作者提出 SelectDB Serverless 的解决方案，通过计算、缓存、存储三层独立解耦，支持秒级原地纵向伸缩，单集群最高16倍弹性区间，并采用“扩快缩慢”策略——CPU 5秒均值或内存瞬时利用率超过60%触发扩容，CPU与内存同时低于30%且持续1分钟才渐进缩容，同时引入AI辅助决策。文章还给出选型参考：峰谷特征明显、可释放计算资源超过28%时Serverless才具成本优势；纵向弹性有16倍边界，极端场景需横向伸缩约3分钟。内容主要基于产品设计与机制说明，缺少独立用户验证数据。
推荐收录，因为它不只是产品宣传，而是提供了具体的弹性架构设计：三层资源解耦、扩缩容触发阈值、原地纵向伸缩机制和选型成本阈值，对云数仓、Serverless 或弹性架构设计的读者有直接参考价值。可迁移的是“扩快缩慢”的弹性策略和计算/缓存/存储解耦思路；需注意其厂商视角，部分性能数据未经独立验证。
文章复盘学科网阅卷系统从 MySQL 迁移到 TiDB 的实践，背景是业务具有峰谷特征、单机 MySQL 主备集群出现容量与性能瓶颈，同时研发资源有限无法改造代码。作者详细说明选型 TiDB 的关键理由：高度兼容 MySQL 实现零代码迁移、在线 DDL 不阻塞业务、弹性扩缩容适配流量波动、Raft 多副本保证数据强一致。迁移采用分批策略，优先将大表和主从延迟严重的表迁入，收益包括缓解并发压力、消除切换数据不一致风险、节省磁盘空间并避免分库分表改造。文中还总结了扩容规划、小表热点处理、低峰版本升级和索引优化等运维经验。该方案尤其适合教育行业等需要兼容 MySQL 且短时高并发的场景，但需注意跨 AZ 缩容的数据分布和热点小表的处理。
推荐收录，因为文章提供了真实业务约束下的数据库选型、迁移和运维全过程，包含零代码改造、在线 DDL、强一致、扩容规划、小表热点等具体细节，不是泛泛的技术宣传。适合数据库架构师、SRE 以及教育行业技术负责人参考，其“先兼容迁移、争取时间”的平滑演进思路可迁移到其他受限于 MySQL 单机瓶颈且短期无法大改代码的团队。
本文详细介绍了Netflix实时分布式图（RDG）的查询服务层设计，阐述如何在高吞吐、低延迟要求下高效查询包含数十亿节点和边的图。文章首先分析了浅宽与深窄两类查询场景的挑战，随后说明广度优先遍历、异步优先架构、选择性缓存等关键设计决策及其取舍。接着以具体查询为例，逐步展示请求解析、存储读取、层次化遍历、并行执行、智能过滤和缓存等环节的实现与优化。最后给出系统性能指标（P50/P99延迟、缓存命中率）和经验总结，强调前沿思维、尽早过滤、有界并行和缓存策略等通用原则。其方法适用于高并发、IO密集型的分布式图查询系统，但一致性模型为最终一致，且依赖特定内部存储。
本文是Netflix技术博客的深度工程案例，展示了在真实约束下构建高性能图查询层的完整思考过程，包含具体的设计权衡、量化效果和可迁移原则。适合分布式系统工程师、架构师以及需要处理图数据查询的开发者参考。文中的广度优先遍历策略、异步执行模型和智能缓存方法可直接应用于类似的大规模在线服务场景，有效降低延迟和资源消耗。
文章系统回顾了携程从Kubefed到Karmada的多集群治理演进，重点围绕架构选择、生产落地和规模化优化展开。核心方法是在联邦层保留低频全局能力（资源分发、策略表达、跨集群迁移），将高频局部能力（实时扩缩容、流量切换）留在成员集群，并通过权重驱动的状态机实现数十万Pod的平滑跨集群迁移。文中详细分析了Karmada控制面在几十万级资源规模下遇到的高频状态同步、启动延迟和200G内存尖峰等问题，以及通过折叠Work、降低更新频率、分批对账、watch list等优化手段。适用边界是交易型业务的Kubernetes多集群场景，强调联邦控制面不应成为运行时强依赖。
本文是来自携程生产一线的深度工程案例，不仅解释了为什么从Kubefed切换到Karmada，更给出了清晰的架构原则、迁移机制和规模化治理细节。文中200G内存尖峰、每秒数百次Work更新导致409冲突等具体数据有很强说服力，优化思路可直接指导类似场景。适合云原生平台团队、SRE和架构师参考，可迁移的职责边界划分和控制面优化方法在多集群治理领域有长期参考价值。
文章复盘了一次 MySQL 生产事故：一个长事务导致 InnoDB 版本历史膨胀，使读查询成本随并发量平方级增长，最终拖垮数据库。作者运用 Gunther 通用可伸缩性定律解析了争用系数 α 与一致性开销系数 β，阐明为何超过临界并发数后吞吐量反而下降。解决方案是将 Vitess 事务池从一万降低到约一千并引入排队，模拟原有线程池的反压行为，从而避免大量并发请求涌入存储引擎。配置变更后，系统在类似流量尖峰下吞吐稳定、无报错，MySQL 内部并发数控制在两百以内。文章强调此策略适用于悲观锁、热点行等高争用场景，且思路可迁移至 Postgres 等系统。
推荐收录，因为文章通过真实事故展示了并发与吞吐的逆向关系，并用通用可伸缩性定律提供量化分析。对负责高并发数据库、稳定性工程及反压机制设计的读者具有直接参考价值，可迁移到类似数据库和分布式系统中。文中提供的实验数据和配置对比使其结论可信，且明确给出了适用边界。
本文介绍了 Meta 广告排序系统在大规模序列学习上的两项架构创新：多阶段序列模型将计算密集的离线用户建模与对延迟敏感的在线排序解耦，通过异步处理长用户历史并缓存嵌入，在不线性增加服务资源的前提下提升模型容量；密集 tokenization 和目标感知多头注意力让模型直接从数据中学习稀疏特征与行为序列的交互，取代手动特征工程。该设计带来了可预测的 LLM 式扩展规律，即性能随计算量呈对数线性增长，并总结出模型形状平衡、多阶段可调性、序列组成多样性和语义特征表征四个扩展杠杆。文章给出了在 Instagram 和 Facebook 上的转化率与点击率提升数据，并指出该架构已作为 GEM 模型的核心组件，可泛化至各类广告排序任务。
推荐收录，因为文章不仅公开了关键技术细节（离线/在线解耦、密集 tokenization、目标感知注意力），还系统论证了在广告推荐领域建立起可预测扩展规律的方法与实验证据。对于推荐系统、广告架构及大规模模型服务的工程师和研究者，文中分离建模阶段以平衡复杂度与延迟的思路具有很强的可迁移性，而扩展规律的识别路径可为探索其他大规模机器学习系统提供参考。
Salesforce内部可观测平台Argus需处理每分钟40亿指标，原单区域架构导致全局可用性风险及高昂的数据传输成本。团队采用地理本地化策略，将指标就近处理和存储，避免全量复制，并通过联盟查询层与Elasticsearch元数据映射实现智能路由，仅查询数据所在区域，减少跨区域开销。同时引入HTTP 206部分响应和UI提示来处理部分地域不可用，保障用户体验。文章还介绍了通配符查询的元数据缓存优化，以及持续容量规划和架构审查来维持隔离边界。该方案已在五个生产区域中的四个上线，显著降低爆炸半径，但跨区域延迟和流量成本仍为后续关注点。
这篇工程案例详实记录了如何将单区域可观测平台迁移到多地理架构，解决全局不可用风险并控制成本，包含查询联邦、部分失败处理和元数据缓存等关键设计，为构建高可靠、大规模可观测系统的团队提供了可复用的架构思路和实践参考。
文章复盘 ClickHouse Cloud 如何把自动扩缩容推荐服务从固定定时轮询改造成秒级反应式架构。原实现按固定节奏扫描全部服务，导致周期之间发生 OOM 或负载突增时必须等到下一次 tick 才能扩容，问题本质是延迟而非推荐逻辑错误。作者复用 Kubernetes 生态的 controller-runtime 作为通用事件处理引擎，把周期性扫描与反应式快路径都抽象为 source，统一投递到带键去重、指数退避和并发上限的工作队列，由同一个幂等 reconcile 函数产出推荐，因此无需自研触发协调机制。反应式信号以事件行写入 ClickHouse 专用小表，由物化视图在写入时过滤越阈指标，source 每几秒执行一次五分钟窗口查询，使关键事件在数秒内触发扩容；周期性全量扫描仍保留作为安全网与缩容兜底。文章也明确边界：工作队列仅存在于单进程内存，无持久化与重放，它是电平触发的 reconcile 引擎而非流处理器，不支持事件时间窗口、join 或跨事件聚合，轮询间隔构成反应速度下限；若未来需要保证投递、严格顺序或状态化窗口关联，应迁移到流式平台。
推荐收录：文章给出完整的问题定义、架构改造路径和可复现的 Go 与 SQL 片段，把“用 controller-runtime 当通用事件引擎、用 ClickHouse 存反应式信号”这一非显然选择连同去重、退避、并发控制的收益讲清楚。对做自动扩缩容、Kubernetes 控制器或实时信号管道的工程师有直接迁移价值；同时明确标注内存队列无持久化、轮询间隔是延迟下限等约束，避免读者误用。
本文介绍了Meta如何将广告推荐基础模型GEM的训练规模提升至LLM级别，并在12个月内将端到端训练效率提升一倍至20-25%模型算力利用率（MFU），同时训练算力规模扩大4倍。文章从计算效率和扩展效率两个维度分别展开：计算效率通过定制化推荐内核库（Jagged Flash Attention、Generalized Dot-Product Attention、BlockAttention）和混合超低精度训练（MXFP8注意力与MLP）实现；扩展效率则依靠拓扑感知的5D并行策略（2D FSDP加专家并行处理稠密参数，全分片2D模型并行处理稀疏参数）配合SM-free通信、自动激活检查点及序列长度感知负载均衡。所提方案针对推荐系统特有的变长序列、非对称交互和数值敏感性等挑战进行了专门设计，其方法论和具体技术对大规模推荐模型训练具有参考价值，但部分优化（如内核定制）与特定GPU架构强相关，迁移时需适配自身硬件和数据特性。
本文是真实的工业级工程案例，完整展示了在数千GPU上训练万亿参数推荐模型的全栈优化过程，涵盖内核、精度、并行、网络和内存的协同设计，而非孤立技巧罗列。适合负责大规模深度学习训练、推荐系统基础设施或GPU性能优化的工程师，可迁移价值在于其将MFU分解为计算效率和扩展效率的分析框架，以及针对混合架构和变长数据的特定解决方案，对类似规模系统的构建与调优具有直接借鉴意义。
文章介绍了 Cloudflare 推出的 @cloudflare/computer 早期预览版，这是一个面向 AI 代理的运行时库，其核心是基于 SQLite 的持久化共享文件系统，并支持在 isolate 和容器等多种执行后端之间按需切换。作者阐述了传统容器化在代理规模化时面临的扩展性瓶颈，并对比了 isolate 在启动速度、水平扩展和成本上的优势，提出了以 isolate 为主、容器仅用于必要任务的混合架构。文中给出了从 npm 安装到配置 workspace、绑定工具集和集成 agent 循环的代码示例，并解释了 FUSE 挂载、动态 worker 命令转译等实现机制。其目标是让代理 90% 以上的工作负载在 isolate 中完成，从而大幅降低对容器平台的需求，但目前仍处于实验阶段。
推荐收录，因为文章不仅停留在产品发布，而是深入讨论了 isolate 与容器作为代理计算基元的架构取舍，并给出了可落地的设计思路和代码示例。对正在构建大规模代理系统、关注基础设施效率和成本控制的后端工程师或平台工程师而言，文中关于水平扩展、文件系统抽象和执行后端分离的经验可迁移至类似场景。
本文提出基于通用可扩展性定律（USL）的大语言模型（LLM）计算动力学模型，用以解释OpenAI在训练LLM时观察到的计算高效前沿（CEF）。USL在标记化的神经网络景观中定义了双稳态极小值，其中更深的极小值决定了LLM实例可达到的最低损失。作者指出，规模更大的LLM具备与CEF幂律斜率对齐的更深的全局最小值，这表明CEF是更大规模模型捕获跨语料相关性的自然结果。文章为LLM可扩展性提供了理论框架，但模型依赖于对神经网络景观和标记化的假设，可能未涵盖所有实证因素。
该文章从通用可扩展性定律出发，为LLM训练中的计算高效前沿提供了新颖的理论解释，对理解缩放法则具有长期参考价值。适合关注LLM可扩展性、深度学习理论和性能建模的研究者与工程师阅读。其跨领域迁移价值在于将经典可扩展性理论与现代AI模型相结合，但需注意模型的理论假设可能与实际训练细节存在差距。
本文是 Spotify 工程团队对 2026 年 6 月 24 日播客视频发布延迟事故的完整复盘。事故由四个因素叠加造成：视频转码基础设施余量不足、定时批处理任务争用容量、为提升画质降低码率而抬高的单项处理成本，以及硬件迁移后调度 bug 导致约 10% 算力未被利用，最终形成数小时的发布积压并引发创作者重复上传。文章给出精确到分钟的 UTC 时间线，指出从首批告警到正式响应延误约四小时，并列出已采取的处置动作（停止批处理、修复调度 bug、扩容、次日凌晨清空队列）与整改计划（容量提升约 67%、改进监控、优先级调度、限流与背压、创作者通知）。局限在于仅覆盖单一公司管线，未披露具体架构细节与量化验证结果。
推荐收录：这是一份结构完整、证据具体的事故复盘，明确列出四个叠加根因、分钟级时间线与处置及整改动作，展示了容量规划、队列优先级和背压设计的真实取舍。适合负责媒体处理、数据管线或高可用服务的工程师参考，其中告警与响应脱节、批处理与实时流量争抢资源的教训可直接迁移。
文章回顾了 Dropbox 内部内容处理平台 Riviera 近十年的演进历程。平台最初为解决多文件格式预览需求而设计，关键思路是将每项任务拆解为可复用的转换片段（如 PowerPoint→PDF→图像），从而避免为每个产品单独构建管道。架构上采用中心调度器与插件化后端 worker 分离的模式，中心负责请求验证、缓存与编排，worker 按转换类型独立扩展，现已支持 300+ 文件格式与 100 多种转换能力，每秒处理数十万请求。随着产品线扩展，Riviera 被搜索、视频审阅、电子签名及 AI 产品 Dash 等团队复用，为 AI 模型统一提供文档提取与格式转换。文章最后说明了平台向外部开发者开放 API 和 MCP 工具的策略，体现了“一次构建、多方受益”的平台工程价值。文章侧重于架构决策与规模效益，未深入具体实现细节或失败案例。
推荐收录。文章提供了真实的大型内容处理平台从单点服务到多产品基座的演进案例，清晰展示了复用、分离关注点和插件化架构如何支撑规模增长与业务扩展。适合平台工程、基础设施设计以及需为 AI 准备非结构化数据的工程师参考，其架构思维和平台化策略具有直接迁移价值。不足之处在于缺少性能瓶颈、失败处理或维护成本的讨论，但整体工程经验仍具有长期参考意义。
Marc Brooker在这篇博客中介绍了Aurora DSQL论文，重点阐述了系统的整体目标：构建一个简化应用构建与运维、无需关心规模与可靠性的关系型数据库。文中强调了架构解耦的设计思想，将查询处理、事务、复制和控制面拆分为独立服务，并总结了来自Aurora与DynamoDB等系统的运营教训，如避免大缓存、提供强一致可扩展读、将昂贵操作下推到存储层。作者还讨论了乐观并发控制（OCC）在避免客户端阻塞和减少尾延迟方面的优势，以及多区域场景下的快速读写能力。博客最后指出，硬件与数据中心设计的进步使得强一致性成为更优选择，并提供了论文链接供进一步阅读。
作为Aurora DSQL系统的核心设计者之一，作者以第一视角提炼了论文的关键设计决策与运营经验，浓缩了现代分布式OLTP数据库的核心理念。文章对解耦架构、一致性选择、多区域扩展等问题的论述既权威又简明，适合分布式系统工程师、架构师及关注数据库技术演进的研究者快速获取全局认知，其总结的教训可迁移至其他大规模系统设计。
本文介绍了 Meta 广告漏斗深度优化中的层级兴趣表征系统，旨在通过统一嵌入连接用户、广告主与产品。系统基于大规模异构交互图，融合多模态世界知识（由 LLM 处理）以缓解稀疏信号问题，并采用 Transformer 架构实施层级编码：引入图结构偏差的注意力机制（使用 FlexAttention 实现内存高效计算）、自监督跨视图蒸馏（结合 Sinkhorn-Knopp 均衡）与交互预测联合训练。最终输出通用嵌入和“意义包”离散令牌，可服务于检索、排序等下游任务。文章详细阐述了图构建、在线基础设施、因果性保证与规模化训练流水线，提供了工业级推荐系统在复杂图学习上的工程实践，但方法高度依赖 Meta 内部平台与数据规模，迁移时需考虑领域适配。
推荐收录。本文来自 Meta 工程博客，系统披露了用于大规模广告推荐的上游层级兴趣表征系统，完整覆盖从图构建、多模态知识融合、Transformer 层级编码到在线推理的工程细节，并公开了 FlexAttention、跨视图蒸馏等具体设计决策与缩放经验。适合推荐系统、图学习及大规模 ML 基础设施方向的研究者和工程师参考，可迁移至处理稀疏信号、层级表征与工业级图应用的场景。需注意部分架构深度绑定 Meta 生态，但核心思想与权衡思路具备通用价值。
文章从数据库扩展瓶颈出发，解释了单节点和只读副本在写入吞吐、数据容量和备份速度上的局限，进而说明为何分片是超越数TB数据的必需方案。以存储1PB数据、跨越256个分片共768台服务器的场景为例，文章重点阐述代理层如何通过查询解析、路由规划和连接池，将众多分片对外表现为单一数据库。文中介绍了基于哈希的分片策略、JSON拓扑配置，并给出从应用经网络负载均衡到代理再到分片的完整数据流。文章主要提供架构层面的概览与工具选择（Neki for Postgres、Vitess for MySQL），而非深入实现细节，适合正在规划数据库扩展的工程师建立整体认知。
该文以清晰的架构图和具体规模为例，系统梳理了数据库分片的核心挑战与代理层设计，对理解分片系统的整体运作有实际参考价值。适合需要应对数据量增长的研发、DBA和基础设施工程师，可迁移的分层架构与路由思想能直接指导技术选型和方案设计。
本文详细介绍了Netflix构建实时服务拓扑系统的完整工程历程，涵盖架构设计、生产环境挑战与持续优化。系统采用流式优先的三阶段分布式聚合流水线，结合反向压力、动态一致性哈希和时间窗口聚合器，实现了对网络流日志、IPC指标的高吞吐处理与历史拓扑查询。文章重点分析了Kafka消费滞后、热点节点、内存与GC压力、响应式流复杂性等关键问题，并通过重分布、使用可变数据结构替代不可变对象、更换通信协议等务实手段解决。作者强调，在超大规模下测量驱动迭代优化比遵循教条更重要，同时也指出了响应式流心智模型的高成本。该案例为构建大规模分布式数据流水线提供了可迁移的架构模式与性能调优经验，但部分技术选型需结合自身场景评估。
本文收录理由在于它提供了从0到1构建大规模服务拓扑系统的完整工程案例，而非浅层介绍。作者坦诚分享了架构权衡、失败教训和优化方法论，对分布式系统、流处理和可观测性领域的工程师有直接参考价值。可迁移的核心经验包括多阶段重分布解决数据倾斜、背压实现优雅降级以及性能优化时的务实取舍，但采用时需结合自身规模与技术栈做适配。
本文拆解了腾讯混元 Hy3 preview 在 Hopper 96G 上的推理全栈优化，围绕算子优化与融合、并行策略、多级缓存、MTP 异步调度、量化与稀疏五个方向展开。作者针对 Attention、MoE、Router、采样、AllReduce 等关键路径做了动态调度、双 BF16 GEMM、FusedMoE、通算融合和算子级融合，显著减少 HBM 往返与 Kernel 启动开销。系统层面又通过 TPSP、DP+EP、三级缓存和按最大接收长度预组装输入，缓解长上下文、MoE 与 MTP 带来的通信、显存和 CPU 气泡问题。文中给出了真实请求集与多组实测指标，如 TTFT 降幅约 24.5%~29.9%、端到端吞吐提升 15.7%~44.7%、量化后吞吐提升 28%+、稀疏注意力在 128K 上将 Prefill 延迟降低 3.6 倍。整体方法高度依赖 Hopper 架构、自研 kernel 与腾讯内部基础设施，迁移到其他模型或硬件时需要重新验证边界与收益。
收录，因为文章给出了真实请求集、Hopper 96G 和 W8A8C8 约束下的系统性优化路径，并明确量化了 TTFT、吞吐和单算子加速收益。适合做大模型推理、GPU Kernel 融合、并行与缓存设计的参考，但方案强依赖特定硬件与自研栈，迁移时需重做适配验证。
这篇文章介绍了 Netflix 如何把自研的批处理计算系统 CMB 迁移到 Kubernetes 生态中的 Kueue，以替换原有的排队、调度和容量管理逻辑。作者不仅解释了迁移动机，还详细说明了租户层级、保留容量与共享容量的语义、Cohort/ClusterQueue/LocalQueue 的映射关系，以及如何在不改变用户 API 的前提下完成透明迁移。文章最后总结了高 QPS 配置、先迁最复杂客户、以及引入公平共享和抢占机制等经验，并说明这些改造已在生产中支撑数百万批任务运行。
推荐收录，因为它展示的是一次真实的大规模批处理平台重构，而不是单纯介绍一个开源工具。文章对多租户容量管理、调度语义迁移、灰度与回滚、以及生产吞吐保障都有具体做法，具备很强的可迁移参考价值。
这篇文章介绍了 ChatGPT 记忆系统从“手动保存记忆”演进到基于后台自动归纳的 dreaming 机制，重点解决记忆陈旧、正确性和规模化成本三个问题。文章还给出了评估记忆质量的三个维度：持续携带上下文、遵循偏好与约束、随时间保持最新，并说明新架构如何通过记忆摘要页让用户查看和管理被合成的记忆。整体上它展示的是一个已经进入产品化部署的 AI 个性化系统设计，而不是单纯的功能宣传，适合作为 AI 工程与产品化记忆系统的参考案例。
推荐收录，因为它把“记忆”从概念层面落到了可评估、可更新、可扩展的系统设计，覆盖了上下文继承、偏好跟随和时间衰减这类真实问题。对做 AI 产品、个性化系统或长上下文状态管理的人来说，这篇文章有较强的迁移价值。
文章复盘了 Instacart 广告召回系统从“对固定候选集打分”转向“按 token 自回归生成”的重构过程。作者先分析了旧式 BERT 检索在词表膨胀、冷启动和候选结构漂移上的瓶颈，再介绍用 Semantic IDs 作为新产品词汇、用上下文模板组织训练输入、以及通过 beam search 生成候选并映射回商品索引的完整方案。为了支撑新模型，团队还重建了 GPU serving 栈（TensorRT-LLM、Triton、Go-native 服务），最终在两条发现型广告位上取得了约 +5% CTR、+34% add-to-carts 的线上收益，并显著提升了长尾类目和品牌多样性。
推荐收录，因为它不是单纯的产品宣传，而是把广告召回从建模、表示、训练、检索到推理基础设施完整串起来，呈现了一个可迁移的工业级重构范式。对于做推荐系统、检索系统和大模型推理落地的读者，这篇文章能直接提供“何时从打分转向生成”“如何重做表示层”“如何为生成式召回重建 serving 栈”的判断框架。
这篇文章讲 Datadog 如何在大规模生产环境中拆解一个共享数据库，核心目标是把原本耦合的业务边界重新切开，同时尽量不影响线上稳定性。作者强调先定义清晰的所有权边界，再通过分阶段迁移、风险隔离和回滚预案降低改造成本，而不是一次性“硬拆”。文中还介绍了用于自动化迁移、校验一致性和减少人工操作的配套工具，以保证解耦过程可重复、可持续。它的重点不在数据库原理本身，而在多团队共用核心存储时如何平衡组织边界、迁移风险和工程效率。其适用前提是已有足够的监控、测试和发布控制能力，若系统变更链路薄弱，收益会被迁移复杂度抵消。
文章直接围绕“shared database at scale”的拆分实践展开，给出了边界划分、风险控制和自动化工具这三类可迁移做法，明显属于可长期参考的工程案例。适合正在做服务解耦、数据库分片/迁移或多团队协作治理的读者，但需要注意其前提是具备较成熟的发布与验证体系。
这篇文章讲的是 Datadog 如何把按租户划分的配置数据，稳定、低延迟地分发到成千上万的工作负载容器中，以支撑实时日志处理场景。核心问题不是单纯“把配置发出去”，而是在容器规模快速增长、租户数量多、更新频繁的情况下，同时保证可用性、传播时延和配置一致性。文章强调了面向大规模分发系统的工程化设计思路，包括可靠传输、失败恢复以及对性能目标的持续验证。它的价值在于展示了一个典型的基础设施系统如何在多租户和高吞吐约束下做取舍，并把配置分发变成可运营、可扩展的能力。适用读者主要是做平台、基础设施、可观测性或大规模后台系统的工程师。其边界在于这是特定于配置分发与实时日志处理的经验，迁移时仍需结合自身配置变更频率、容器生命周期和一致性要求。
推荐收录，因为标题与摘要直接表明它解决的是“千级容器配置分发”的真实工程问题，且明确关注低延迟与高可靠两类核心指标。对平台、可观测性和多租户后台系统的读者，这类分发架构、稳定性设计和扩展性权衡具有较强迁移价值。
文章围绕数据库在云上扩容时最容易被忽视的 IOPS 和吞吐量成本展开，先解释 AWS EBS 中 IOPS 的计量方式、顺序/随机读写对有效带宽的影响，以及 gp3、io1、io2 的配额与价格差异。随后作者用 RDS、Aurora 和 PlanetScale 的月费对比，说明当单体数据库从中等规模增长到 8 倍需求时，单机方案往往要付出显著更高的 I/O Premium。文章的核心观点是：对 I/O 密集型数据库，分片可以把计算、存储和 I/O 压力拆散到多个 primary 上，从而继续使用更便宜的存储层。文中还指出分片带来的额外收益包括故障隔离、备份更快和长期线性扩展，但没有给出实际压测结果，因此结论更偏成本与架构层面的比较，而非纯性能评测。
文中直接用 EBS 的 IOPS/吞吐限制和三种数据库方案的月费对比，证明了单体扩容会迅速推高 I/O 成本，而分片能把需求摊平到多个 shard 上。适合做数据库容量规划、云成本评估和分片选型的读者；但价格结论依赖区域、流量形态和分片键设计，落地时需要按自身 workload 复算。
文章以一个健身应用中的 exercise_log 大表为例，解释为什么少数高增长表会先成为数据库瓶颈：写入频繁、历史数据持续被查询，最终把存储、内存和 IO 都推到极限。作者先讨论纵向扩容，即通过增加 CPU、内存和磁盘来延长单机数据库的可用寿命，但指出当数据达到多 TB 时，成本和资源争用会迅速上升。接着介绍垂直分片，把大表从主库中拆出到独立 keyspace，并借助 Vitess 的 MoveTables 平滑迁移和切流，使主业务表与日志表可以分别扩展。最后给出水平分片方案：按 user_id 做哈希分布、使用 sequence 生成全局 ID，再通过 Reshard 把单表扩到多个 shard。文章还总结了分片带来的吞吐提升、备份加速、故障隔离和成本优化，同时提醒分片键选择会直接影响查询局部性和性能。
推荐收录，因为文章明确给出了大表扩容的三级演进路径，并直接展示了 Vitess 的 MoveTables、Reshard 和分片键设计等可操作证据。适合做数据库架构、MySQL 扩容和日志/消息类大表治理的参考，但读者需要结合自身读写模式谨慎选择分片键。
这篇文章系统介绍了数据库分片的三种常见策略：directory/lookup-based、range-based 和 hash-based，并用示例说明它们如何根据 shard key 将数据分散到不同分片。作者分别分析了每种方法的优缺点：目录式分片便于按业务规则精确路由，但依赖额外的查表步骤，且容易因数据倾斜或热点访问造成单分片压力；范围分片实现直观，但如果范围划分不合理，很容易出现分布不均，需要通过 reshard 调整；哈希分片通常能获得更均匀的数据分布，代价是要做哈希计算，并且仍需谨慎选择高基数且符合访问模式的 shard key。文章还强调，分片方案不是点击按钮即可完成，真正落地时要结合数据分布、访问模式和后续扩容计划一起考虑。PlanetScale 的倾向是把 hash-based 作为默认选择，因为它通常最均衡、复杂度也更低，但这并不意味着它适合所有场景。
文章直接给出了三类分片策略的机制、优缺点和适用边界，属于数据库扩展的基础参考，而不是单纯的产品介绍。适合正在设计 MySQL/分库分表方案、评估 shard key 或做容量规划的读者阅读。
文章复盘 Datadog 将内部 job system 迁移到 Kubernetes 后，如何压低平台引入的额外开销。作者指出瓶颈并不只在业务计算本身，而常出现在容器启动、调度等待、资源分配和节点利用率等环节。随后通过调整任务模型、批量与复用策略、以及更合理的资源请求配置来减少空转和抖动。文中强调迁移收益不能只看单点指标，而要结合吞吐、尾延迟和资源成本做端到端评估。它适合需要把批处理或异步任务迁到容器编排平台的工程团队参考，但具体方案仍受作业形态与隔离要求限制。
推荐收录，因为标题直接指向“minimized the overhead”和“moving a jobsystem to Kubernetes”，属于典型的真实工程优化案例。对做批处理平台、容器化迁移和成本优化的读者尤其有价值，可迁移的方法是用端到端指标分析调度与资源开销，而不是只盯业务代码。