Backend System Design
Backend system design is the set of decisions that lets a request travel from the user to data and back reliably. This section is a durable reference for balancing scalable APIs, data consistency, performance, reliability, observability, security, and cost.
When To Use This Section
- When defining the boundaries, data ownership, and API contract of a new backend service.
- When an existing system shows latency, error-rate, cost, or operational-complexity problems.
- When comparing trade-offs around monoliths, microservices, event-driven systems, cache, queues, sharding, or multi-region designs.
- When AI or external resources are limited and you need to quickly recall the core principles.
Core Flow
Every box in this flow is a decision point: a gateway centralizes control but can become a bottleneck; cache reduces latency but adds consistency risk; queues absorb bursts but introduce delay and replay handling.
Decision Compass
| Question | Start Here | Typical Trade-off |
|---|---|---|
| Is one service enough? | Monolith vs Microservice | Simple operations vs independent scaling |
| How will the API evolve? | API Versioning | Backward compatibility vs maintenance load |
| How do we reduce read pressure? | Caching | Low latency vs invalidation complexity |
| How do reads and writes scale? | Sharding, Replication | More capacity vs data distribution cost |
| How do we limit failure spread? | Circuit Breaker, Backpressure | Protection vs extra state management |
| How consistent must the data be? | Strong vs Eventual Consistency, CAP | Correctness perception vs availability |
| How will the system be observed? | Logging, Metrics, Tracing | Visibility vs data volume and cost |
| How are access and secrets protected? | Auth, Secret Management, TLS/mTLS | Security vs integration complexity |
| How do we explain the problem and architecture? | System Thinking, Requirements and C4 | Clarity vs documentation cost |
| How do we estimate capacity? | Back-of-the-Envelope | Fast assumptions vs measurement accuracy |
| Where is the transaction boundary? | ACID and Isolation | Strong guarantees vs throughput |
Minimum Design Check
Before calling a backend design complete, clarify these points:
- Problem: Which user or business flow does the system support, and what is the most critical failure mode?
- Solution: Are the main components, data-owning services, and sync/async boundaries clear?
- Trade-off: Are rejected alternatives and their reasons explicit?
- Example: Is there at least one successful request, one failure path, and one retry/idempotency flow?
- Measurement: Are latency, throughput, error rate, saturation, and cost signals defined?
- Security: Are authentication, authorization, secrets, TLS, and audit needs covered?
- Cost: Is the price of cache, queues, data copies, observability, and multi-region choices understood?
Section Map
0. Architectural Thinking and Design Process
1. Basic Concepts
2. Performance and Scalability
3. Reliability and Consistency
- Failover
- Circuit Breaker and Bulkhead
- Health Checks
- Backpressure
- ACID, Isolation, and Distributed Transactions
- Consistency Models
- Consensus Algorithms
4. API, Microservices, and Data Flow
- API Gateway
- Rate Limiting
- GraphQL vs REST vs gRPC
- Microservice Communication
- Service Discovery
- Event Sourcing
- CQRS
- Stream Processing
- Batch Processing and MapReduce
5. Operations, Security, and Geography
- Observability
- Observability Stack
- Security
- Cloud and Containers
- SRE
- Operations and Cost
- Edge and Multi-Region
- DNS, CDN, and Request Path
- Continuous Improvement
15. Large-Scale System Design Scenarios
Starting Route
If you are new, read System Thinking, Requirements and C4, Back-of-the-Envelope, Request-Response Model, Database Concepts, Caching, Observability Stack, and Large-Scale Scenario in order. When designing a system, pull only the decision you need from each section; adding unnecessary technology is maintenance debt, not system design.