技术架构
S3
S3 的五大核心设计原则
Amazon S3 自 2006 年发布至今，其底层设计原则从未改变，支撑了从 1PB 到数百 EB 的规模化演进：
- Security：数据默认受保护
- Durability：11 个 9（99.999999999%）的设计目标，系统以无损方式运行
- Availability：假设故障始终存在，必须在每一层设计中处理
- Performance：存储任意量数据而不降级
- Elasticity：随数据增减自动伸缩，无需人工干预
"When we get these things right, the service becomes so straightforward that most of you never have to think about how complex these concepts are."
见：Twenty years of Amazon S3 and building what's next：AWS 官方博客回顾 S3 二十年演进
规模即优势（Scale is to your advantage）
S3 的反直觉架构哲学：规模是优势而非负担。工程师刻意设计系统使规模增长改善所有用户的系统属性——S3 越大，工作负载的去相关性越强，可靠性反而提升。微服务持续巡检集群每个字节，规模扩大时检测能力同步增强；自动修复系统在数据退化时立即触发， 规模效应使修复资源池更充裕。
"The larger S3 gets, the more de-correlated workloads become, which improves reliability for everyone."
见：Twenty years of Amazon S3 and building what's next：S3 VP Mai-Lan Tomsen Bukovec 与 Gergely Orosz 的技术访谈
极简技术栈架构——$20/月支撑 $10K MRR
Steve Hanov 用月成本约 $20 的技术栈支撑多个 $10K MRR 产品：Linode/DigitalOcean VPS（$5–10/月）、Go 后端（静态编译单二进制，scp 部署）、SQLite + WAL 模式（
PRAGMA journal_mode=WAL 支持读写并发）、二手 RTX 3090 本地运行 VLLM 处理批量 AI 任务、OpenRouter 统一接入 frontier model 并自动 fallback、
GitHub Copilot（利用其按请求计费的定价模型）。
核心架构逻辑是用约束倒逼简洁设计：1GB 内存排除了 Python/Ruby 等重型运行时，倒逼选择 Go 的静态编译；单台服务器排除了分布式复杂度，倒逼 SQLite 本地文件 + WAL 模式； 本地 GPU 的一次性投入替代了持续 API 调用成本。有分析认为这种架构在重写入场景下存在扩展瓶颈，但对读多写少的 SaaS 产品足够支撑到数万用户。
见：How I run multiple $10K MRR companies on a $20/month tech stack
相关资料
认证过程
用户密码
如何储存用户密码？
除开双因素认证等鉴权方式，单看用户密码的落库。一般人都知道不能明文存储，但是简单的加密也并不安全：MD5、SHA-1、SHA-256 等哈希算法，都可以通过彩虹表等方式破解。所以，一般会选择加盐哈希算法，比如 bcrypt、scrypt， 并采用多层加密策略。
加盐过程有哪些容易出现的错误？
盐太短或重复使用都会导致问题，此外，应该使用安全的随机函数生成盐，如 C/C++ 的 CryptGenRandom。
什么是 Password Hashing？
加盐哈希在现代计算机来看已经不够安全，Password Hashing 应当能应付以下几种攻击：
- 加密算法破解（原值还原、哈希碰撞等）
- 查表、彩虹表
- CPU 优化攻击
- GPU、FPGA、ASIC 等专用硬件攻击
- 旁路攻击：通过检测电磁波、功耗等信息来推算信息
How Dropbox securely stores your passwords
Dropbox 的密码存储策略是什么
- 将用户密码使用 sha256 归一化，因为 bcrypt 的结果对长度敏感
- 使用 bcrypt 每用户加盐加密
- 使用 AES256 全局加密，并使用专用的硬件及定期更换策略等
此外，Dropbox 表示也在关注 Argon2 等竞赛新秀。