Cosmos DB（Mongo DB）租户及部门数据预归档删除最佳实践咨询

1. 异步化+限流分页归档，避免阻塞主业务 #

• 把删除部门/租户的操作拆为异步任务流，前端触发后先给管理员返回「删除请求已受理，归档完成后自动执行删除」的提示，后台走独立的任务队列处理归档逻辑，完全不占用主业务请求的响应资源
• 归档查询不要一次性拉全量，用部门ID作为分区键做限流分页查询：比如每次查100_{500条，每次查询后强制休眠100}200ms，把RU消耗平摊到更长的时间窗口，避免峰值抢占业务请求资源
• 归档查询统一加readPreference=secondaryPreferred配置，优先从从节点拉取数据，完全不影响主节点的业务写入性能

2. 变更前加资源隔离标记，避免归档期间数据不一致 #

• 管理员触发删除操作后，先给对应部门/租户加上「删除中」的状态标记，业务层拦截所有对该资源的写入请求，提示「该部门/租户正在删除中，无法操作」，避免归档过程中产生新数据导致归档不全
• 如果业务允许短暂只读，可以调整拦截规则，只禁止写入、放开只读权限，对普通用户的影响更小

3. 数据库侧原生/周边工具能力替代自研查询 #

• 如果你用的是MongoDB Atlas，直接启用Online Archive能力，配置按部门ID/租户ID的归档规则，冷数据会自动归档到对象存储，你只需要在删除时触发归档规则执行即可，完全不用自己处理数据拉取、上传的逻辑，RU消耗也由官方侧做了隔离不会影响主业务
• 如果是自建MongoDB，可以在同一K8s集群/服务器上部署轻量的mongodump Sidecar容器，业务代码通过内部接口调用Sidecar执行归档命令：删除部门场景支持指定--query参数按部门ID过滤数据，删除租户场景直接全库导出即可，归档生成的dump文件直接上传到Blob存储即可，比自研查询的性能高3~5倍，资源消耗也更低

4. 归档校验+兜底重试机制 #

• 归档完成后必须做校验：比对归档数据的文档数、核心字段的聚合值和数据库内的对应数据是否一致，校验通过再执行删除操作
• 归档任务支持断点续传、失败重试，避免大文件上传失败导致整个删除流程阻塞

内容的提问来源于stack exchange，提问作者grifoxx