最常考的系统设计warm-up——这题卡壳后面更难的就没机会了。
澄清：读写比（常见100:1）、过期策略、是否允许自定义alias、是否要点击统计。
容量：1亿写/天≈1160写QPS、10万读QPS。存储：1亿*365*5年≈2000亿URL。每条500字节→100TB。
ID生成两种：(1)Hash(长URL)→base62短码；冲突retry+增量。(2)分布式计数器（snowflake）+base62——无冲突但ID顺序可猜。
存储：KV（Cassandra/DynamoDB）以短码为key。上Redis缓存——URL访问长尾分布，命中率90%+。
CDN/边缘：热门短链边缘返回。全球读<10ms。
我先问：每天多少URL、允不允许自定义、要不要点击分析、过期多久。1亿/天≈1200写QPS、10万读QPS（按100:1）。ID我用分布式计数器+base62——snowflake给64位单调ID、base62缩到10-11字符。公开URL"可猜"没关系；业务要求不可猜就hash+salt或加密随机。存储Cassandra按短码分片，上面Redis LRU。最热1%短码前面挂CDN。写入靠本地ID区段分配批量化，DB只看10 QPS而不是1200。常见追问：自定义别名（去重）、防刷（按用户和域限速）、点击统计（异步写Kafka）。
Base62（a-zA-Z0-9）7字符有62^7≈3.5万亿个组合，短链管够。
别拿MD5做短码——冲突且可猜。计数器+base62或随机更好。
即答侠存了参考设计文档——白板上不用现算QPS/存储。
太长（36字符）。用户要的是7-10字符。UUID也不大致有序，B+树写性能差。
单独命名空间——写入时DB查重，冲突返409。保留一批"系统"前缀避免冲突。