本文由 AI 分析生成
建立時間： 2026-03-28 來源： https://danluu.com/simple-architectures/
Summary
Dan Luu’s case study of Wave (African fintech) running a simple synchronous Python monolith with a single database at top-100 site traffic levels. The thesis: complex microservice architectures get disproportionate conference coverage, but for most applications at most scales, a boring monolith is cheaper to build and operate.
Dan Luu 關於 Wave（非洲金融科技公司）以簡單的同步 Python 單體和單一數據庫處理 top-100 網站流量的案例研究。論點：複雜的微服務架構在會議上獲得過多關注，但對於大多數應用程序和大多數規模，無聊的單體更便宜、更易於構建和操作。
Key Points
- Wave runs a synchronous Python monolith + single DB at billions of requests/month; engineering team cost dominates infrastructure cost
- Conference circuit heavily over-indexes microservices: 6 talks on microservice complexity vs. 0 on monoliths at a major conference
- Chose boring sync Python over async frameworks (Eventlet) after bugs; CPU waste from blocking I/O is acceptable at their scale
- Long-running tasks farmed to a queue (not async app) — a simple, reliable alternative to async everywhere
- Honest about non-simplicity trade-offs: on-prem data residency requirements (Africa regulations) added unavoidable complexity; telecom integrations required custom work to avoid prohibitive SaaS SMS costs
- Regrets: SQLAlchemy implicit session management caused subtle bugs; RabbitMQ/Celery added complexity that Redis + simpler queue would have avoided
Insights
Wave is a rare documented case of a successful large-scale business deliberately choosing boring technology and reporting the results honestly. The framing — “spend your complexity budget where it benefits the business” — is more useful than blanket “use microservices” or “always use monoliths.” The actual cost calculation (engineering team >> infrastructure) is often missing from architecture discussions. The candid accounting of regrets (SQLAlchemy, Celery) is valuable: these are widely-used tools that introduce subtle costs in practice. The on-prem/regulatory complexity is unavoidable — this is an honest acknowledgment that “keep it simple” has limits driven by external constraints, not design choices.
Connections
Raw Excerpt
By keeping our application architecture as simple as possible, we can spend our complexity (and headcount) budget in places where there’s complexity that it benefits our business to take on.