5 guides
Data and consistency
Start here for database indexes, transactions, locking, sharding, and eventual consistency.
Learning path
System design for backend developers
A curated path through 15 backend system design guides, built around real production tradeoffs instead of abstract architecture diagrams.
5 guides
Database performance and operations
Diagnose query explosions, tune connection pools, plan migrations, and keep database-backed APIs stable.
5 guides
Reliability and resilience
Learn how production systems handle dependency failures, retries, duplicate work, and overload.
5 guides
Async processing
Understand queues, background jobs, webhooks, and the operational details behind async workflows.
5 guides
Traffic and API architecture
Study how requests reach backend services and how public API contracts stay stable over time.
Start here
Pillar guides
These articles are the strongest entry points into the system design cluster.
System Design Jun 28, 2026 4 min read
Database Indexes Explained
Learn how database indexes work, why they speed up reads, when they slow down writes, and how backend developers should choose indexes.
System Design Jul 1, 2026 5 min read
N+1 Query Problem Explained
Learn the N+1 query problem in backend apps, including ORM loading, SQL examples, eager loading, batching, joins, query counts, and fixes.
System Design Jul 1, 2026 6 min read
Database Connection Pooling Explained
Learn database connection pooling for backend systems, including pool size, timeouts, leaks, max connections, queues, monitoring, and common mistakes.
System Design Jul 1, 2026 6 min read
Database Migration Rollback Explained
Learn database migration rollback strategies, including backward-compatible changes, expand-contract migrations, backups, deploy order, and recovery plans.
System Design Jun 29, 2026 5 min read
Caching Strategies Explained
Learn common backend caching strategies, including cache-aside, write-through, write-behind, TTLs, invalidation, and cache stampede risks.
System Design Jun 29, 2026 4 min read
Message Queues Explained
Learn how message queues work in backend systems, including producers, consumers, retries, dead-letter queues, ordering, and idempotency.
System Design Jun 29, 2026 4 min read
Database Transactions Explained
Learn what database transactions are, why ACID matters, how commits and rollbacks work, and what backend developers should know.
System Design Jun 29, 2026 4 min read
Circuit Breaker Pattern Explained
Learn how the circuit breaker pattern protects backend services from cascading failures, with closed, open, and half-open states.
API Design Jun 29, 2026 4 min read
API Gateway Explained
Learn what an API gateway does in backend architecture, including routing, authentication, rate limiting, observability, and tradeoffs.
How to study
Follow tradeoffs, not buzzwords.
System design becomes easier when you connect patterns to concrete pressure: read latency, write throughput, query count, connection pressure, duplicate side effects, stale data, overloaded dependencies, and operational recovery.
Use the topic cluster as a map. If an article mentions retries, queues, idempotency, or transactions, follow those links and compare why each pattern exists.
For the broader index of all site clusters, browse Topics.
FAQ
System design learning questions
What should I learn first in backend system design?
Start with database indexes, N+1 query diagnosis, transactions, connection pooling, caching, queues, and rate limiting. These topics appear in real backend systems before more advanced distributed architecture patterns.
Are these system design guides only for interviews?
No. The guides are written for practical backend work, but they also help with interview preparation because they explain tradeoffs, failure modes, and implementation details.
How should I use this learning path?
Read one cluster at a time, follow the related links inside each article, and compare patterns that solve similar problems, such as retries, idempotency, queues, and circuit breakers.
Do I need all of these patterns in a small application?
Usually not. Small systems should start simple. These guides help you recognize when a pattern becomes worth its added operational complexity.