Learning path · Intermediate
System design basics
How big systems are shaped, scaled and kept running when parts fail.
The vocabulary of system design interviews and architecture reviews: the shapes a system can take, how it grows, how it survives failure, and the principles that keep it maintainable.
33 pages4 chaptersabout 1 hours of reading
- Software Architecture
- Backend & APIs
- DevOps & Cloud
- Databases
Not started yet0/33 read
Start with Client-Server ArchitectureProgress comes from your reading history, kept only in this browser.
Chapter 1Shapes of a system
- 1Client-Server ArchitectureSoftware Architecture, p. 6Client-server architecture splits a system into clients, which request data or actions, and servers, which provide them, as when a browser requests a page.
- 2MonolithSoftware Architecture, p. 28A monolith is a software application built and deployed as a single unit, where all features share one codebase, one process, and usually one database.
- 3MicroservicesSoftware Architecture, p. 27Microservices are an architectural style where an application is split into small, independently deployable services that communicate over a network.
- 4Distributed SystemSoftware Architecture, p. 14A distributed system is a set of computers that work together over a network and appear to their users as a single system.
- 5Layered ArchitectureSoftware Architecture, p. 25Layered architecture splits an application into horizontal layers, such as presentation, business logic, and data access, each calling only the layer below it.
- 6Event-Driven ArchitectureSoftware Architecture, p. 18Event-driven architecture is a software design style in which services communicate by producing and reacting to events, such as an order being placed.
- 7API GatewayBackend & APIs, p. 3An API gateway is a server that sits in front of a group of backend services and acts as the single entry point that receives, checks, and routes API requests.
- 8Service DiscoverySoftware Architecture, p. 38Service discovery is how services in a distributed system find the current addresses of other services, which change as instances start, stop and move.
- 9Backend for FrontendSoftware Architecture, p. 2Backend for frontend is an architecture pattern in which each kind of client, such as a web or mobile app, gets its own small backend tailored to its needs.
Chapter 2Scaling up
- 10ScalabilitySoftware Architecture, p. 36Scalability is a system's ability to handle growing amounts of work, such as more users or data, by adding resources without a drop in performance.
- 11Vertical ScalingSoftware Architecture, p. 47Vertical scaling (scaling up) increases a system's capacity by giving a single machine more CPU, memory or faster storage, instead of adding more machines.
- 12Horizontal ScalingSoftware Architecture, p. 23Horizontal scaling (scaling out) increases a system's capacity by adding machines and spreading the work across them, rather than making one machine bigger.
- 13Load BalancerDevOps & Cloud, p. 34A load balancer is a server or service that spreads incoming traffic across several backend servers so no single one is overloaded and the app stays available.
- 14CacheBackend & APIs, p. 8A cache is a fast, temporary storage layer that keeps copies of frequently used data so later requests can be served quickly without repeating slow work.
- 15CDNDevOps & Cloud, p. 7A CDN is a network of servers spread around the world that stores copies of website content and delivers it to each user from the nearest location.
- 16Database ReplicationDatabases, p. 10Database replication is the continuous copying of data from one database server to others, so several servers hold the same data for reliability and scale.
- 17ShardingDatabases, p. 39Sharding is a way of scaling a database by splitting its data across several servers, called shards, so each one stores and handles only part of the total.
- 18Consistent HashingSoftware Architecture, p. 9Consistent hashing spreads keys across a changing set of servers so that adding or removing a server moves only a small share of the keys.
- 19Message QueueBackend & APIs, p. 29A message queue is a component that stores messages from one service until another is ready to process them, so parts of a system can work asynchronously.
Chapter 3Staying up
- 20High AvailabilitySoftware Architecture, p. 22High availability is the ability of a system to stay operational nearly all the time, mainly by removing single points of failure through redundancy.
- 21Fault ToleranceSoftware Architecture, p. 20Fault tolerance is the ability of a system to keep working correctly, perhaps at reduced capacity, when some of its hardware or software components fail.
- 22Consensus AlgorithmSoftware Architecture, p. 8A consensus algorithm lets a group of machines agree on a single value or an ordered log of decisions, even when some of them crash or messages are lost.
- 23Circuit Breaker PatternSoftware Architecture, p. 4The circuit breaker pattern protects a system by stopping calls to a failing dependency for a while and failing fast instead of waiting on timeouts.
- 24Rate LimitingBackend & APIs, p. 37Rate limiting is a technique that caps how many requests a client can make to a server or API within a time window, protecting it from abuse and overload.
- 25IdempotencyBackend & APIs, p. 24Idempotency is the property of an operation that produces the same result whether it runs once or many times, so accidentally repeating a request is safe.
- 26Saga PatternSoftware Architecture, p. 35The saga pattern runs a transaction spanning several services as a sequence of local steps, undoing completed steps with compensating actions if one fails.
- 27Eventual ConsistencyDatabases, p. 19Eventual consistency is a guarantee that, if no new updates are made, all copies of a piece of data in a distributed system will become identical over time.
Chapter 4Designing well
- 28Separation of ConcernsSoftware Architecture, p. 37Separation of concerns is a design principle that divides a program into distinct parts, each responsible for one clearly defined aspect of its behavior.
- 29Loose CouplingSoftware Architecture, p. 26Loose coupling is a design principle in which components depend on each other as little as possible, so one can change without breaking the others.
- 30CohesionSoftware Architecture, p. 7Cohesion is a measure of how closely the responsibilities inside a module, class, or service belong together, and high cohesion is a sign of good design.
- 31Domain-Driven DesignSoftware Architecture, p. 15Domain-driven design is an approach to building software that models the code closely on the business domain, using the same language as the domain experts.
- 32CQRSSoftware Architecture, p. 10CQRS is an architectural pattern that separates the code that changes data, called commands, from the code that reads data, called queries, into two models.
- 33Event SourcingSoftware Architecture, p. 17Event sourcing is a design pattern that stores every change to an application's state as an immutable event and rebuilds current state by replaying them.
Along the way, compare
Pairs on this path that are easy to mix up, side by side.