Awesome Architecture · 架构图谱
An open-source knowledge base about architecture — not code. Battle-tested architecture maps of real, popular systems, paired with a tutorial that trains you to think like an architect.
English · 简体中文
🌐 Read online (interactive · bilingual, HTTPS): https://study8677.github.io/awesome-architecture/en/
🧭 Companion skill: architecture-copilot — turns this knowledge into an interactive skill that guides you through architecture design inside Claude Code / Cursor / Codex.
Why this repo exists
For the past two decades, a programmer's core edge was writing code correctly and fast.
But something is happening right in front of us: "writing code" is disappearing. Not getting harder, not getting scarcer — ending, as a craft that humans do. At frontier labs like OpenAI and Anthropic, almost all code is already written by AI; human engineers no longer type out implementations by hand. They do just two things: tell the AI what to build, then judge whether it got it right. Once a machine spits out working code in seconds, knowing "for vs map, that API, this syntax" — the old craft — is worth nothing overnight.
What isn't depreciating — and is in fact getting more valuable — is a different skill:
Before you write the first line of code, figure out what the system should actually look like.
Where does data come from, where does it go? What must be strongly consistent, what can be eventual? Where will it break first? When users grow from 10K to 100M, what's the first bottleneck? To get A, which B am I willing to give up?
That is architectural thinking. It's independent of language, of framework, even of what's trendy this year. It's the judgment to read the map before you hit the road.
Our belief: the great developer of the future is first a person who makes sound architectural judgments, and only second a person who writes code. Understand what you're building at the architecture level first — code is just one way to make that understanding real.
What's inside
awesome-architecture/
├── tutorial/ 📚 Tutorial — systematically teaches you how to *think like an architect*
└── templates/ 🗺️ Templates — architecture maps of real systems; architecture only, no syntax📚 tutorial/ — Become a sharper architect
Not "how to use framework X", but a transferable way of thinking: how to turn a vague requirement into constraints, how to make decisions under trade-offs, how to draw architecture diagrams that actually communicate, and how to design a brand-new system from scratch.
| Ch. | Topic | What you'll learn |
|---|---|---|
| 01 | Why architecture-first thinking | Why "architecture first" is the core skill of this era |
| 02 | The architect's thinking framework | The universal flow: requirements → constraints → quality attributes → trade-offs |
| 03 | Reading & drawing architecture diagrams | Use the C4 model to get the system out of your head and onto paper |
| 04 | 10 core architecture patterns | Layered, microservices, event-driven, CQRS… what each one actually solves |
| 05 | Data & state | Why data is the real hard part of any system |
| 06 | Quality attributes & trade-offs | Performance / availability / consistency / cost — how to weigh them |
| 07 | Designing a system from 0 to 1 | A step-by-step methodology you can actually follow |
| 08 | ADRs & evolution | Record decisions with ADRs and let architecture grow with the business |
| 09 | Architectural taste | What separates good architects beyond the framework; grow judgment via real cases (microservices→monolith, big-company tastes) |
👉 New here? Start with tutorial/README.md for the full learning path.
🗺️ templates/ — Architecture maps of real systems
Each template is an "architecture map". We deliberately avoid discussing language or framework — only: what problem this class of system solves, what parts it's made of, how data flows, how the key trade-offs are made, and where it dies at scale.
Classic / general systems
| Template | Representative products | Key architecture themes |
|---|---|---|
| AI Chat Product | Claude, ChatGPT | LLM inference, streaming, context management, RAG, cost control |
| Browser Extension | Honey, Grammarly | Content/background split, page injection, privacy boundaries, monetization |
| Standard Web App | Corporate sites, blogs, SaaS dashboards | Classic three-tier, caching, read/write splitting — "good enough" |
| Mobile App | Most iOS/Android apps | Offline-first, data sync, client state, push |
| E-commerce Platform | Amazon, Shopify, Taobao | Inventory, orders, payments, overselling, traffic spikes |
| Social Feed | Twitter/X, Instagram | Feed push/pull, follow graph, viral fan-out |
| Video Streaming | Netflix, YouTube | Transcoding, CDN, adaptive bitrate, recommendations |
| Realtime Chat | WhatsApp, Slack, WeChat | Long-lived connections, message ordering, offline delivery, group fan-out |
| URL Shortener | Bitly, TinyURL, t.co | Read-heavy, caching, 301/302, distributed unique IDs |
| Payment System | Stripe, Alipay, PayPal | Idempotency, double-entry ledger, reconciliation, state machine |
| Search Engine | Google, Elasticsearch | Inverted index, relevance ranking, recall + rerank, sharding |
| Ride-Hailing | Uber, Lyft, DiDi | Geospatial index, real-time location, supply–demand matching |
| Collaborative Doc | Google Docs, Figma | OT/CRDT, single-writer serialization, operation log |
| Cloud Storage | Dropbox, iCloud | Chunking, content-addressed dedup, incremental sync |
| Notification System | Novu, FCM/APNs | Multi-channel fan-out, dedup/throttling, async retry |
| Online Ticketing | Ticketmaster, 12306 | Virtual waiting room, atomic stock decrement, seat-lock TTL |
🤖 AI-native systems (new)
| Template | Representative products / prototypes | Key architecture themes |
|---|---|---|
| AI Gateway / Relay | One API, LiteLLM, Portkey | Unified API, billing & rate-limit, load balancing, caching |
| RAG Knowledge Base | RAGFlow, LlamaIndex, Dify | Chunking, vector retrieval, hybrid search + rerank, citations |
| AI Agent / Workflow | Dify, Coze, LangGraph | Action loop, tool sandbox, memory, guardrails |
| Inference Serving | vLLM, SGLang, Triton | Continuous batching, paged KV cache, quantization |
| Vector Database | Milvus, Qdrant, pgvector | ANN, HNSW/IVF, recall–latency trade-off |
👉 Want to add your own template? Follow the unified format in templates/_TEMPLATE.md.
📝 Now fully bilingual — all 9 tutorial chapters and 21 templates are available in English. Use the language switch (top-right on the site), or browse
en/in the repo.
How to use this repo
If you're a beginner / shifting toward architectural thinking: Read tutorial/ in order. After each chapter, pick a system in templates/ you find interesting and try to "read" it using the framework you just learned.
If you're about to design a new system: Start with tutorial/07 for the methodology, then find the map closest to your scenario in templates/. Treat it as a starting point, not an answer — walk through its "key decisions" and "common pitfalls" and ask yourself each one.
If you're prepping for system design interviews: Every template covers high-frequency topics (overselling, feed fan-out, message ordering, streaming output…), all in a consistent format — great for systematic review.
If you're a senior engineer / architect: Jump straight to each template's "Key Decisions & Trade-offs" and "Evolution Path" — the most concentrated parts. PRs sharing the scars you've earned are welcome.
Three reading principles
- Ask "why" before "how". Every architecture choice sits on top of a constraint or a trade-off. If you can't see the trade-off, you haven't understood it.
- There is no best architecture, only the most fitting one. "Chat" for an internal tool and "chat" for WeChat are worlds apart. Scale, team, cost, and compliance decide everything.
- Architecture grows. Don't force a mature-stage architecture onto an MVP. Every template includes an "evolution path" telling you when to upgrade — and when you're over-engineering.
The one-sentence version
Code tells the computer what to do; architecture decides whether the thing is worth doing, can be done, and will hold up. This repo trains you for the second kind of judgment.
Contributing
Contributions are welcome — new templates, fixes, and especially English translations of the tutorial and existing templates.
- Copy
templates/_TEMPLATE.mdinto a new folder, e.g.templates/your-system/README.md. - Fill in all 14 sections (including real reference-prototype links) and stay strictly at the architecture level — the moment you start writing "use library YY in language XX", stop and ask: is this an architecture decision, or an implementation detail?
- Draw diagrams in ASCII (plain text, viewable everywhere, never breaks).
- Add a row to the template list.
The bar: an engineer who has never touched this domain can, after reading your template, explain "why this class of system is designed this way, and where it dies".
🔗 Friends
- LINUX DO — "Where possible begins." A new ideal-type community for developers who love tech and sharing.