Slack多客户仅邮箱登录的实现方式及架构方案问询

核心思路：全局索引+分片存储+租户逻辑隔离 #

Slack能仅靠邮箱完成登录，核心是解决了「多租户/多域名场景下快速定位用户存储位置」的问题，而非全库扫描，具体拆解如下：

1. 邮箱到用户的快速定位：全局反向索引 #

Slack维护了一个轻量全局分布式索引库，只存储关键映射关系：

• 存储内容：邮箱哈希值（加盐SHA-256，避免明文泄露）、用户ID、所属租户ID、用户数据所在的分片标识（数据库集群ID/节点ID）
• 存储选型：采用高可用的分布式KV存储（如Cassandra或自定义分布式存储），因仅存元数据，数据量小、查询QPS极高，能支撑数百万级并发查询
• 查询流程：用户输入邮箱后，系统先对邮箱做哈希处理，查这个全局索引，直接拿到用户所在的分片和租户信息，跳过全库扫描的低效操作

2. 登录验证的完整流程 #

1. 哈希邮箱查全局索引，获取用户元数据（租户ID、分片位置、用户ID）
2. 根据分片标识，路由到对应的用户存储集群，拉取该用户的完整登录信息（密码哈希、MFA状态、租户登录规则等）
3. 在目标分片集群内完成验证（密码校验、MFA验证等），同时校验租户自定义的登录策略（如是否允许SSO、IP限制）
4. 验证通过后生成会话凭证（如带租户ID和用户ID的JWT），后续请求通过凭证路由到对应的租户服务节点

3. 多租户/多域名的架构支撑 #

• 分片存储策略：用户数据不是按客户独立建库，而是按「用户ID哈希/租户ID哈希」做分片，同一个租户的用户大概率落在同一组分片内，兼顾资源利用率和租户数据的聚合性。每个分片是独立的数据库集群（如PostgreSQL集群），负责存储分片内的用户、团队、消息数据
• 逻辑租户隔离：即使同一分片内有多租户数据，所有查询都会强制带上租户ID作为过滤条件，从业务层彻底隔离不同租户的数据，避免越权访问
• 域名-租户映射：邮箱域名（如xxx@company.com）会和租户ID绑定并存入全局索引，输入邮箱时也可先通过域名快速缩小租户范围，进一步优化查询效率

4. 性能与高可用保障 #

• 热点缓存：活跃用户的邮箱-元数据映射会缓存到Redis等内存存储，降低全局索引的查询压力，提升登录响应速度
• 水平扩展：分片集群支持按需扩容，新增分片后全局索引自动更新分片标识，无需停机
• 故障转移：全局索引和分片集群均采用多副本部署，单个节点故障时自动切换到副本，不影响登录流程

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