Project Overview
Awesome Scalability is a curated reading list of patterns, papers, blog posts, and talks for building scalable, reliable, and performant large-scale systems. Maintained by Binh Nguyen, the repository organizes hundreds of links into a structured reference covering everything from load balancing and caching to distributed consensus and incident management.
This is not a code library or framework. You won't install anything from it. What you get is a single-page index of battle-tested resources organized by system design topic, with enough breadth to cover the full stack of scaling problems — from database sharding to organizational scaling. With over 71,000 GitHub stars, it has become one of the most widely bookmarked system design references on GitHub.
If you're building or maintaining systems that need to handle growth — in traffic, data, or team size — this is a solid starting reference.
Key Challenges Addressed
Finding good scalability resources is harder than it should be. The best material is scattered across engineering blogs (many behind corporate domains that reorganize URLs every year), academic papers, conference talks, and book chapters. You can spend hours searching and still miss the canonical reference for a topic.
Awesome Scalability addresses three specific problems:
- **Discovery**: grouping resources by topic (caching, messaging, databases, consensus, observability) so you find what you need without trawling search engines.
- **Vetting**: the community has surfaced and starred the list for years, which acts as a rough quality filter. Links that are consistently useful survive; links that aren't get replaced.
- **Breadth coverage**: most individual blog posts or courses cover one slice of scalability. This list covers the full surface — availability, performance, reliability, data infrastructure, microservices, security at scale, and even organizational scaling patterns.
The gap it fills is the space between "I've read the CAP theorem Wikipedia page" and "I need to design a system that handles 50,000 requests per second with five-nines uptime." The list won't teach you everything, but it points you to the people and papers that will.
Getting Started
Clone or bookmark the repository — there's nothing to install:
The entire list lives in a single README. Open it and use the table of contents to jump to the topic area you need. Don't try to read it top-to-bottom; that's a fast path to burnout. Instead, pick the section that matches your current problem.
If you're new to distributed systems, start with the **Principles** and **Scalability** sections before jumping into specifics like consensus algorithms or message queue comparisons. Read two or three linked articles per topic, then move on. You'll retain more from targeted deep dives than from skimming fifty tabs.
One sharp edge: link rot hits curated lists hard. Some URLs point to blog posts that have been moved, paywalled, or taken down entirely, and you get a silent 404 with no indication of what was there. If you hit a dead link, search for the article title on the Wayback Machine at web.archive.org or paste the title into a search engine — the content usually still exists somewhere.
Features and Use Cases
The list covers system design topics across several major areas:
- **Infrastructure patterns**: load balancing, caching, CDNs, DNS, reverse proxies, and connection pooling. Each section links to both introductory explanations and production war stories.
- **Data layer**: database scaling (sharding, replication, partitioning), NoSQL vs. relational trade-offs, data pipelines, and stream processing. You'll find links to papers on Dynamo, Bigtable, and Spanner alongside practical posts about migrating to sharded PostgreSQL.
- **Reliability and availability**: circuit breakers, retries, bulkheads, chaos engineering, and incident management. The section on failure modes is particularly useful — it links to real postmortems.
- **Distributed systems fundamentals**: consensus (Paxos, Raft), distributed transactions, vector clocks, CRDTs, and consistency models. These links tend toward academic papers, but many have accompanying blog post explanations.
- **Microservices and architecture**: service mesh, API gateways, event sourcing, CQRS, and domain-driven design at scale. Useful when you're past the "should we use microservices" question and into "how do we actually operate them."
- **Observability and monitoring**: metrics, logging, tracing, alerting, and dashboarding. Links to both tooling comparisons and philosophy pieces on what to measure.
- **Organizational scaling**: team structure, on-call practices, and engineering management patterns. Most people skip this section and shouldn't — scaling humans is harder than scaling servers.
**Common use cases**: preparing for system design interviews, auditing your architecture before a scaling push, onboarding new engineers onto infrastructure concepts, and building a personal reading curriculum for distributed systems.
Ecosystem and Dependencies
Awesome Scalability doesn't have dependencies in the traditional sense — it's a curated index. But it connects to a broader ecosystem of learning resources.
System Design Primer is the most common companion resource. Where Awesome Scalability gives you a categorized link list, System Design Primer provides structured lessons with diagrams and exercises. Use both: the Primer for guided learning, Awesome Scalability for deep reference dives.
System Design 101 offers visual explanations of system design concepts that complement the text-heavy resources in Awesome Scalability. The diagrams are particularly helpful for understanding data flow and component interaction.
The list itself references tools and projects across the infrastructure stack: Kafka, Redis, Nginx, Kubernetes, Prometheus, Grafana, and dozens more. It's not an integration guide, but the linked articles often include implementation details for these tools in production contexts.
If you maintain internal engineering documentation, Awesome Scalability works well as a seed for a team reading list. Pull the sections relevant to your stack, add your own internal resources, and use it as an onboarding reference.
Architectural Overview
The repository structure is minimal: a single README.md organized by topic headings with a navigable table of contents. Each section contains a curated list of links with brief descriptions.
The organizational scheme follows a practical decomposition of system design concerns:
1. **Principles** — foundational concepts and mental models
2. **Scalability** — horizontal and vertical scaling patterns
3. **Availability** — redundancy, failover, and replication
4. **Stability** — circuit breakers, timeouts, backpressure
5. **Performance** — caching, CDNs, optimization techniques
6. **Intelligence** — machine learning infrastructure at scale
7. **Architecture** — microservices, event-driven, serverless patterns
8. **Monitoring** — observability, alerting, incident response
This flat-file structure has a real advantage: everything is searchable with Ctrl+F, and the entire reference loads in a single page. No framework, no build step, no navigation hierarchy to learn. The downside is that you can't filter by difficulty level or by your specific technology stack — you get everything or nothing.
The table of contents at the top acts as the primary navigation. Each section heading links to its position in the document, making it easy to bookmark specific topics.
Pros and Cons
**Pros:**
- Covers the full breadth of scalability topics in one place. You won't find many blind spots across infrastructure, data, reliability, and organizational scaling.
- Community-vetted through years of stars, forks, and contributions. Low-quality links tend to get replaced over time.
- Zero setup cost. Bookmark it and start reading. No accounts, no paywalls, no tooling.
- Language and stack agnostic. The resources cover patterns and principles, not specific implementations, so the content applies regardless of your technology choices.
- Star growth of 42% over the last ~6 months signals sustained community interest, meaning the list continues to attract contributors who add and update links.
**Cons:**
- No guided learning path. You get a flat list, not a curriculum. Without prior context, you won't know which resources to prioritize or what order to read them in.
- Link rot is real. Some linked articles have been moved, paywalled, or taken down. There's no automated link-checking, so you'll occasionally hit dead ends.
- Quality varies across links. Community vetting is a rough filter, not a guarantee. Some linked articles are deep and excellent; others are surface-level overviews that won't teach you much.
- No hands-on exercises or code examples within the list itself. You read about patterns but don't practice implementing them here.
- Can be overwhelming. The sheer volume of links makes it easy to open fifty tabs and read none of them. You need self-discipline to use it effectively.
Comparison and Alternatives
GitHub stars
Weekly star gains
Full metrics details
GitHub GraphQL current stargazer cohort, reconstructed from starredAt events and totalCount retrieved in one stable pagination walk. GitHub does not expose historical unstar events, so this is not an exact ledger of past star counts.
Awesome Scalability
GitHub GraphQL current stargazer cohort, reconstructed from starredAt events and totalCount retrieved in one stable pagination walk. GitHub does not expose historical unstar events, so this is not an exact ledger of past star counts.
180 observed daily rows. Missing days are not fabricated.
| Date | Value |
|---|
System Design
GitHub GraphQL current stargazer cohort, reconstructed from starredAt events and totalCount retrieved in one stable pagination walk. GitHub does not expose historical unstar events, so this is not an exact ledger of past star counts.
154 observed daily rows. Missing days are not fabricated.
| Date | Value |
|---|
Issues opened
Weekly total
Full metrics details
GitHub API observation. Historical values render only when the source provides a real observation for that day.
Awesome Scalability
GitHub API observation. Historical values render only when the source provides a real observation for that day.
178 observed daily rows. Missing days are not fabricated.
| Date | Value |
|---|
System Design
GitHub API observation. Historical values render only when the source provides a real observation for that day.
142 observed daily rows. Missing days are not fabricated.
| Date | Value |
|---|
Issues closed
Weekly total
Full metrics details
GitHub Search issue totals queried for exact UTC days; rolling values are sums of proven daily counts.
Awesome Scalability
GitHub Search issue totals queried for exact UTC days; rolling values are sums of proven daily counts.
178 observed daily rows. Missing days are not fabricated.
| Date | Value |
|---|
System Design
GitHub Search issue totals queried for exact UTC days; rolling values are sums of proven daily counts.
142 observed daily rows. Missing days are not fabricated.
| Date | Value |
|---|
Pull requests opened
Weekly total
Full metrics details
GitHub API observation. Historical values render only when the source provides a real observation for that day.
Awesome Scalability
GitHub API observation. Historical values render only when the source provides a real observation for that day.
178 observed daily rows. Missing days are not fabricated.
| Date | Value |
|---|
System Design
GitHub API observation. Historical values render only when the source provides a real observation for that day.
142 observed daily rows. Missing days are not fabricated.
| Date | Value |
|---|
Pull requests closed
Weekly total
Full metrics details
GitHub Search pull-request totals queried for exact UTC days; rolling values are sums of proven daily counts.
Awesome Scalability
GitHub Search pull-request totals queried for exact UTC days; rolling values are sums of proven daily counts.
178 observed daily rows. Missing days are not fabricated.
| Date | Value |
|---|
System Design
GitHub Search pull-request totals queried for exact UTC days; rolling values are sums of proven daily counts.
142 observed daily rows. Missing days are not fabricated.
| Date | Value |
|---|
Pull requests merged
Weekly total
Full metrics details
GitHub API observation. Historical values render only when the source provides a real observation for that day.
Awesome Scalability
GitHub API observation. Historical values render only when the source provides a real observation for that day.
178 observed daily rows. Missing days are not fabricated.
| Date | Value |
|---|
System Design
GitHub API observation. Historical values render only when the source provides a real observation for that day.
142 observed daily rows. Missing days are not fabricated.
| Date | Value |
|---|
Open/closed pull request ratio
Weekly average
Full metrics details
GitHub Search pull-request totals queried for exact UTC days; rolling values are sums of proven daily counts.
Awesome Scalability
GitHub Search pull-request totals queried for exact UTC days; rolling values are sums of proven daily counts.
180 observed daily rows. Missing days are not fabricated.
| Date | Value |
|---|
System Design
GitHub Search pull-request totals queried for exact UTC days; rolling values are sums of proven daily counts.
154 observed daily rows. Missing days are not fabricated.
| Date | Value |
|---|
Open/closed issues ratio
Weekly average
Full metrics details
GitHub Search issue totals queried for exact UTC days; rolling values are sums of proven daily counts.
Awesome Scalability
GitHub Search issue totals queried for exact UTC days; rolling values are sums of proven daily counts.
180 observed daily rows. Missing days are not fabricated.
| Date | Value |
|---|
System Design
GitHub Search issue totals queried for exact UTC days; rolling values are sums of proven daily counts.
154 observed daily rows. Missing days are not fabricated.
| Date | Value |
|---|
Releases
Weekly total
Full metrics details
GitHub release published_at events bucketed by UTC day; drafts are excluded.
Awesome Scalability
GitHub release published_at events bucketed by UTC day; drafts are excluded.
180 observed daily rows. Missing days are not fabricated.
| Date | Value |
|---|
System Design
GitHub release published_at events bucketed by UTC day; drafts are excluded.
154 observed daily rows. Missing days are not fabricated.
| Date | Value |
|---|
Hotness score
Weekly average
Full metrics details
Derived only from GitHub GraphQL starredAt events after daily star totals are reconciled.
Awesome Scalability
Derived only from GitHub GraphQL starredAt events after daily star totals are reconciled.
180 observed daily rows. Missing days are not fabricated.
Per-day formula: 0.40 × Hot today + 0.40 × Hot week + 0.20 × Breakout.
- Same-day multiplier = stars 1d ÷ max(1, stars 7d ÷ 7)
- Weekly multiplier = stars 7d ÷ max(1, stars 30d ÷ 30 × 7)
- Fortnight multiplier = stars 14d ÷ max(1, stars 90d ÷ 90 × 14)
- Hot today = clamp(70 × log-scale(stars 1d, 1000) + 30 × breakout-scale(same-day, 4))
- Hot week = clamp(75 × log-scale(stars 7d, 5000) + 25 × breakout-scale(weekly, 3))
- Breakout = clamp(35 × breakout-scale(same-day, 4) + 40 × breakout-scale(weekly, 3) + 25 × breakout-scale(fortnight, 2.5))
| Date | Stars | Stars 1d | Stars 7d | Stars 14d | Stars 30d | Stars 90d | Same-day multiplier | Weekly multiplier | Fortnight multiplier | Hot today | Hot week | Breakout | Stored score |
|---|
System Design
Derived only from GitHub GraphQL starredAt events after daily star totals are reconciled.
154 observed daily rows. Missing days are not fabricated.
Per-day formula: 0.40 × Hot today + 0.40 × Hot week + 0.20 × Breakout.
- Same-day multiplier = stars 1d ÷ max(1, stars 7d ÷ 7)
- Weekly multiplier = stars 7d ÷ max(1, stars 30d ÷ 30 × 7)
- Fortnight multiplier = stars 14d ÷ max(1, stars 90d ÷ 90 × 14)
- Hot today = clamp(70 × log-scale(stars 1d, 1000) + 30 × breakout-scale(same-day, 4))
- Hot week = clamp(75 × log-scale(stars 7d, 5000) + 25 × breakout-scale(weekly, 3))
- Breakout = clamp(35 × breakout-scale(same-day, 4) + 40 × breakout-scale(weekly, 3) + 25 × breakout-scale(fortnight, 2.5))
| Date | Stars | Stars 1d | Stars 7d | Stars 14d | Stars 30d | Stars 90d | Same-day multiplier | Weekly multiplier | Fortnight multiplier | Hot today | Hot week | Breakout | Stored score |
|---|
Reliability score
Weekly average
Full metrics details
Derived from the displayed continuity, closure, shipping, liveness, and support-burden components.
Awesome Scalability
Derived from the displayed continuity, closure, shipping, liveness, and support-burden components.
180 observed daily rows. Missing days are not fabricated.
Per-day formula: 0.30 × Continuity + 0.30 × Closure + 0.20 × Shipping + 0.10 × Liveness + 0.10 × Support burden.
- Continuity = 35% active ratio 90d + 20% active ratio 30d + 15% PR efficiency 90d + 10% PR efficiency 30d + 10% liveness + 10% observed-history coverage
- Closure = 55% PR merge efficiency 90d + 45% issue close efficiency 90d
- Shipping = 100 × (20% × release ratio 30d + 30% × release ratio 90d + 50% × release ratio 180d); ratios are releases ÷ 2, 6, and 12, capped at 1
- Support burden = 100 − 2 × open issues per 1,000 stars
- Liveness = 100 × exp(−pushed days ago ÷ 120)
Stars, issues, pull requests, and releases are daily observations. Pushed-days and license are repository snapshot-derived inputs and are not independent historical GitHub events.
| Date | Issues opened | Issues closed | PRs opened | PRs merged | Releases | Stars | Open issues | Pushed days ago | Continuity | Closure | Shipping | Liveness | Support burden | License | Observed days | Missing days | Needs healing | Stored score |
|---|
System Design
Derived from the displayed continuity, closure, shipping, liveness, and support-burden components.
154 observed daily rows. Missing days are not fabricated.
Per-day formula: 0.30 × Continuity + 0.30 × Closure + 0.20 × Shipping + 0.10 × Liveness + 0.10 × Support burden.
- Continuity = 35% active ratio 90d + 20% active ratio 30d + 15% PR efficiency 90d + 10% PR efficiency 30d + 10% liveness + 10% observed-history coverage
- Closure = 55% PR merge efficiency 90d + 45% issue close efficiency 90d
- Shipping = 100 × (20% × release ratio 30d + 30% × release ratio 90d + 50% × release ratio 180d); ratios are releases ÷ 2, 6, and 12, capped at 1
- Support burden = 100 − 2 × open issues per 1,000 stars
- Liveness = 100 × exp(−pushed days ago ÷ 120)
Stars, issues, pull requests, and releases are daily observations. Pushed-days and license are repository snapshot-derived inputs and are not independent historical GitHub events.
| Date | Issues opened | Issues closed | PRs opened | PRs merged | Releases | Stars | Open issues | Pushed days ago | Continuity | Closure | Shipping | Liveness | Support burden | License | Observed days | Missing days | Needs healing | Stored score |
|---|
Several other GitHub repositories cover system design and scalability learning. Here's how they compare.
System Design Primer provides structured lessons with Anki flashcards and coding exercises. It's a course, not a link list — better if you want guided learning, but narrower in breadth than Awesome Scalability.
System Design 101 focuses on visual explanations using diagrams and infographics. Strong for visual learners and quick concept reviews, but less depth per topic.
System Design takes a textbook-style approach with chapters and exercises. Good for sequential learners who want to work through topics in order, but covers fewer topics overall.
System Design Interview is specifically focused on interview preparation. If your goal is passing system design interviews rather than building production systems, it's more targeted.
Awesome System Design Resources is another curated list with a similar scope. It's organized differently and includes some resources not found in Awesome Scalability, but has less community history.
The best overall alternative is System Design Primer. It provides structured lessons with diagrams, Anki flashcards, and hands-on exercises — the guided learning approach that Awesome Scalability deliberately omits.
If you're an infrastructure engineer or backend developer who needs a single bookmark for scalability reference material, is the one to use. It covers more ground than any single book or course, and the community contributions keep links reasonably current. Bookmark it, pick the section that matches your current scaling problem, and read two or three articles deep.
Do not try to read the list end-to-end — you'll open a hundred tabs, retain nothing, and burn out on the topic before building anything. Start with the , read one article per subtopic, then move to whichever specific area (caching, databases, messaging) matches the system you're actually building.
