架构选型

背景 社区里关于 MQ 的讨论大多默认了一个前提——这条链路已经决定要异步化了，然后才去争 Outbox 谁负责、幂等表怎么设计、顺序/重试怎么保（#589、#474）。但我在三个项目里反复撞到的是更前置的一个问题： «这条链路，到底该不该

背景 我做了 15 年数据管道，见过太多"削峰"方案，但每次架构评审一坐下来，团队对"削峰该在哪一层做"的共识程度约等于零。 举几个我亲历的场景： - 一个支付回调链路，峰值 30k QPS，日常 5k。团队在应用层加了一个 LinkedB

背景 社区最近有关于服务网格 mTLS 证书 90 天强制轮换的讨论，也有大量超时重试、连接池调优的实战经验。这些话题背后其实有一个更底层的架构分歧：安全能力和可观测性，到底应该由 Sidecar 承载，还是让应用自己内嵌 SDK？ 我在过

背景 热榜上连接池 P99、超时重试、Kafka 事务、mTLS、K8s 探针都被聊透了，站内也已经有几篇关于「重试退避 + 死信」「幂等分层」「异步化 + 幂等」的讨论。但我发现一个更前置的架构分叉没人正面聊过——内部任务到底该走 Kaf