基于AWS SES与CockroachDB的邮件列表数据库实现方案咨询

结合你使用AWS SES和CockroachDB的技术栈，以及避免退回、投诉和脏数据的核心需求，下面针对两种方案给出具体分析和建议：

方案A：邮件验证+TTL自动清理（优先推荐） #

核心优势 #

从源头拦截无效邮箱，直接降低AWS SES的退回率和投诉风险——这对维护SES账号信誉至关重要，一旦退回/投诉率超标，可能导致发送配额受限甚至账号被暂停。

表结构选择：单库合并方案 #

不用分库，直接使用合并表结构：

primary_key, subscribe_name, email, verified, expiry_date

CockroachDB支持条件TTL，可以通过配置只删除verified = FALSE且expiry_date已过期的记录，示例配置语句如下：

CREATE TABLE subscriptions (
    primary_key UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    subscribe_name TEXT,
    email TEXT UNIQUE NOT NULL,
    verified BOOLEAN DEFAULT FALSE,
    expiry_date TIMESTAMP WITH TIME ZONE DEFAULT (now() + INTERVAL '2 days')
) WITH (
    ttl_expiration_expression = 'expiry_date',
    ttl_selection_expression = 'verified = FALSE',
    ttl_job_interval = '1 hour' -- 可根据需求调整清理频率
);

这种方式比分库更简洁，避免跨库维护的复杂度，发送新闻通讯时只需过滤verified = TRUE的记录即可。

降低用户操作成本的优化点 #

验证流程的摩擦可以通过细节优化降低：

• 验证链接直接携带用户信息，点击后自动完成验证，无需额外输入；
• 验证邮件中强调订阅价值（比如“点击查看专属行业资讯”），提升用户验证意愿；
• 允许用户在验证页面直接设置订阅偏好，增加流程的实用性。

方案B：无初始验证+事后状态标记（作为兜底补充） #

适用场景与风险 #

如果完全依赖此方案，初期会有大量无效邮箱进入列表，直接推高SES的退回率，可能触发平台的预警机制。因此更适合作为方案A的补充，处理已验证邮箱后续出现的失效情况。

状态标记的关键指标与阈值 #

结合AWS SES的事件通知（通过SNS接收），可以基于以下指标更新status字段：

• 硬退回（Hard Bounce）：直接标记为invalid，立即从发送列表中移除（这类邮箱是永久无效的，比如不存在的邮箱、域名失效）；
• 软退回（Soft Bounce）：标记为pending_retry，连续3次软退回后改为invalid（比如邮箱满、收件服务器临时故障）；
• 用户投诉（Complaint）：立即标记为complained，永久移除（SES对投诉率有严格限制，必须零容忍）；
• 发送失败：连续5次发送失败（非退回类），标记为invalid。

表结构建议 #

可以在方案A的基础上新增status字段，兼顾初始验证和后续失效处理：

primary_key, subscribe_name, email, verified, expiry_date, status

status可选值：active（正常可用）、invalid（无效）、pending_retry（待重试）、complained（已投诉）。

最终建议 #

1. 优先采用方案A的单库合并版本，利用CockroachDB条件TTL自动清理未验证过期记录，从源头控制脏数据；
2. 搭配AWS SES的SNS事件通知机制，监听退回和投诉事件，更新已验证邮箱的status字段，作为兜底的失效处理；
3. 优化验证流程的用户体验，尽量降低操作摩擦，平衡数据质量和用户转化率。

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