H5 应用容器和奖池活动条由 Cloudflare Workers 上的容器页、overlay 和 EKS 里四个 Spring Boot 服务组成，结构由同源入口、一张凭证两处验签、钱只走交易平台、推送层不存状态和 overlay 固定入口发版五条决策定下。

2019 到 2026 年，七家公司在代码边界、服务边界、部署拓扑、API 聚合和数据契约上都有过真实调整，拼起来能看出微服务规模化之后边界治理往哪儿迁移。

微服务规模增大后我开始补的两类结构化文档，问答体：ADR 记下为什么这样选，catalog-info.yaml 记下这是什么、归谁、依赖什么。

Pete Hodgson 在 KubeCon NA 2025 讲《Feature Flags Suck!》：加开关的代价大多在水下，清理要靠元数据和激励对齐，更根本的是从源头少加，标准那一层交给 OpenFeature。

多仓库微服务的文档体系，我最后用的是中央架构 Repo 加各服务 Repo 内的 /docs/ 目录，再用 Docusaurus 收成统一入口，文档贴近代码，检索入口只有一个。

注册门槛往往会抬高结账流失。Shop Platform 现在的做法是 guest JWT 加 Redis 游客购物车（TTL 48 小时），游客订单靠 order_token 追踪，登录后再合并购物车；buyer-portal 和 buyer-app 在这段体验上还有差别。

从递归解析器、权威 DNS、CDN 导流到边缘 PoP 的完整链路出发，整理 CDN 与 DNS 如何协作，以及网站如何在 DNS 宕机、控制面异常和缓存收敛延迟中争取更好的可用性。

Confluent Kafka 的 topic 分区数按当前业务规模假设算了一轮，起步先按 12 个分区配置。

BFF 与微服务之间到底该共享到哪一步？Shop Platform 的 monorepo 实践之外，共享 contracts、共享 client 和契约测试在 polyrepo 下各有 tradeoff，我目前更倾向其中一种组合。

在 code agent 普及的背景下，我在 Shop Platform 用 ArchUnit 作为可执行的 harness，它在微服务、monorepo 和普通 repo 里的落地方式各不相同。