短链接系统是系统设计面试最经典的题目之一，字节跳动、阿里、腾讯等大厂的后端和架构面试高频出现。它麻雀虽小五脏俱全，涵盖了API设计、数据库选型、哈希编码、缓存策略、水平扩展等核心系统设计概念，是考察系统设计能力的绝佳载体。
需求澄清：功能需求（长链转短链、短链跳转、自定义短码、点击统计）；非功能需求（高可用、低延迟<100ms、读多写少约100:1）。
容量估算：假设月新增1亿短链，写QPS约40，读QPS约4000。存储：500字节/条 × 1亿/月 × 5年 ≈ 300GB。
短码生成方案：Base62编码（a-z, A-Z, 0-9），7位可表示62^7≈3.5万亿个唯一短码。可用分布式ID生成器（Snowflake）+ Base62转换，或哈希（MD5取前N位）。
数据库和存储：NoSQL（DynamoDB/Cassandra）适合高写入吞吐和水平扩展。表结构：short_code(PK), original_url, created_at, user_id, expiry。
缓存和扩展：Redis缓存热点URL（二八定律），CDN全球分发，无状态应用服务器水平扩展，负载均衡。
短链接系统设计思路如下。首先明确需求：核心功能是长链转短链、短链302跳转、支持自定义短码和点击统计。非功能需求是高可用（99.99%）、跳转延迟<100ms、读写比约100:1。容量估算：假设月新增1亿条短链，每条约500字节，5年总存储约300GB，读QPS约4000，写QPS约40。API设计两个核心接口：POST /api/shorten接收原始URL返回短链，GET /{code}执行跳转。短码生成是核心设计点，我推荐分布式ID生成器+Base62编码方案。每个应用节点从Zookeeper获取一段ID范围（比如1~10000），本地递增使用，用完再申请新范围，这样避免了分布式协调开销。将数字ID转为7位Base62字符串，可支持3.5万亿个短码。相比MD5哈希方案，不存在碰撞问题，且短码长度固定。数据库选用DynamoDB或Cassandra，以short_code为Partition Key，天然支持水平扩展。由于读远多于写，在数据库前加Redis缓存层——根据二八定律，20%的热门链接承载80%的流量，缓存命中率会很高。缓存策略是Cache-Aside：先查Redis，miss则查DB并回填缓存。跳转使用302（临时重定向）而非301（永久重定向），因为301会被浏览器缓存，后续请求不经过服务器，无法统计点击量。整体架构：用户 → CDN/负载均衡 → 无状态应用服务器集群 → Redis缓存 → DynamoDB。点击统计异步处理：将点击事件发送到Kafka，由Flink/Spark实时统计和批量聚合。扩展考虑：短码过期用懒删除（读取时判断）+定时任务清理；防滥用加限流（令牌桶算法）；全球部署用多Region + 数据同步。
面试开始一定要先问清需求、做容量估算——这是系统设计面试的标准流程，跳过会扣分。
讨论301和302跳转的取舍是加分点，展示你对HTTP协议和业务需求的理解。
分布式ID生成器方案要讲清楚为什么优于哈希方案（无碰撞、可控长度）。
面试中如果忘了容量计算数字，即答侠可以实时帮你估算。
Base62只用字母和数字，生成的短码可直接放入URL无需编码。Base64包含+和/两个特殊字符，放入URL需要额外编码处理。
如果用分布式自增ID+Base62方案，完全不存在碰撞问题。如果用哈希方案，碰撞时可以在原URL后附加计数器重新哈希，或用布隆过滤器快速判断短码是否已存在。
推荐NoSQL（DynamoDB/Cassandra），原因是读写简单（KV查询为主）、写入量大、需要水平扩展。SQL需要分库分表才能支撑，增加运维复杂度。