Book 09 · Cheat sheet

Software Architecture

Design principles and architectural styles that keep large codebases organized and maintainable.

01Adapter Pattern: The adapter pattern is a structural design pattern that wraps an existing class in a new interface, so code expecting one interface can use an incompatible one.
An adapter translates one interface into another that client code expects.
It lets incompatible classes work together without changing either one.
Object adapters use composition; class adapters use inheritance.
02Backend for Frontend: Backend 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.
A BFF is a backend built for one specific frontend, such as web or mobile.
It aggregates and reshapes data from several services into one response per screen.
It is usually owned by the frontend team.
03Builder Pattern: The builder pattern builds a complex object step by step through a separate builder object, with named steps instead of a long constructor full of arguments.
A builder creates complex objects step by step with named settings.
It solves the telescoping constructor problem.
build() applies defaults and validates before creating the object.
04Circuit Breaker Pattern: The circuit breaker pattern protects a system by stopping calls to a failing dependency for a while and failing fast instead of waiting on timeouts.
A circuit breaker wraps remote calls and stops them after repeated failures.
Closed passes calls through, open fails fast, and half-open tests whether the service recovered.
Failing fast prevents cascading failures and frees up threads and connections.
05Clean Architecture: Clean architecture is a way of structuring software in layers so that the core business rules never depend on frameworks, databases, or user interfaces.
Code is organized in layers: entities, use cases, interface adapters, and frameworks.
The dependency rule: dependencies only point inward, toward the business rules.
Business logic defines interfaces; outer layers implement them.
06Client-Server Architecture: Client-server architecture splits a system into clients, which request data or actions, and servers, which provide them, as when a browser requests a page.
Clients send requests; servers do the work and respond.
Protocols such as HTTP define how they communicate.
Central servers keep data authoritative and security enforceable.
07Cohesion: Cohesion 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.
Cohesion measures how well a module's contents belong together.
High cohesion means one clear responsibility; low cohesion means a grab bag.
The single responsibility principle is a rule for achieving high cohesion.
08Consensus Algorithm: A 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.
Consensus lets machines agree on values or an ordered log despite failures.
Raft and Paxos are the best-known algorithms; Raft is easier to implement.
A leader proposes entries, which commit once a majority stores them.
09Consistent Hashing: Consistent hashing spreads keys across a changing set of servers so that adding or removing a server moves only a small share of the keys.
Consistent hashing maps keys to servers on a hash ring.
Adding or removing a server moves only about 1/n of the keys.
Plain modulo hashing moves almost every key when servers change.
10CQRSCommand Query Responsibility Segregation: CQRS is an architectural pattern that separates the code that changes data, called commands, from the code that reads data, called queries, into two models.
Commands change data; queries read data and never change it.
Each side has its own model, optimized for its purpose.
The read side can use separate, denormalized views or databases.
11Decorator Pattern: The decorator pattern adds behavior like logging or caching to an object by wrapping it in another with the same interface, without changing the original.
A decorator wraps an object with the same interface and adds behavior.
Decorators can be stacked in any combination and order.
It extends behavior without editing existing classes.
12Dependency Injection: Dependency injection is a design technique in which an object receives the other objects it needs from the outside instead of creating them itself.
Dependency injection passes a class the objects it needs instead of letting it create them.
Constructor injection is the most common and most explicit style.
It makes code easier to test, because real dependencies can be swapped for fakes.
13Design Pattern: A design pattern is a proven, reusable solution to a common problem in software design, described as a general template rather than as finished code.
A design pattern is a reusable solution template, not ready-made code.
Classic patterns are creational, structural, or behavioral.
Pattern names give developers a shared vocabulary.
14Distributed System: A distributed system is a set of computers that work together over a network and appear to their users as a single system.
A distributed system is many networked computers acting as one.
It is built for scale, fault tolerance and serving users near them.
Partial failures, lost messages, clock drift and network splits are normal.
15Domain-Driven Design: Domain-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.
DDD shapes code around the business domain and the knowledge of its experts.
A ubiquitous language keeps business terms and code names the same.
Bounded contexts divide a large domain into areas with their own model.
16DRYDon't Repeat Yourself: DRY is a software design principle stating that every piece of knowledge or logic should have one authoritative representation instead of being duplicated.
DRY means each piece of knowledge or logic should live in exactly one place.
Duplicated logic must be changed in several places, which invites bugs.
Extract shared code into functions, modules, constants, or components.
17Event Sourcing: Event 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.
State changes are stored as an append-only sequence of immutable events.
Current state is rebuilt by replaying events, often starting from a snapshot.
It provides a complete audit trail and makes it possible to reconstruct past states.
18Event-Driven Architecture: Event-driven architecture is a software design style in which services communicate by producing and reacting to events, such as an order being placed.
Components communicate by publishing and consuming events.
Producers don't know which consumers exist, which keeps services loosely coupled.
An event broker or message queue stores and delivers the events.
19Factory Pattern: The factory pattern is a creational design pattern that moves object creation into a dedicated function or class, so callers never name the concrete class.
A factory centralizes object creation behind a single function or class.
Callers depend on an interface, not on the concrete class being created.
Variants include the simple factory, the factory method, and the abstract factory.
20Fault Tolerance: Fault tolerance is the ability of a system to keep working correctly, perhaps at reduced capacity, when some of its hardware or software components fail.
Fault tolerance keeps a system working correctly when components fail.
A fault is a problem in one component; a failure is when the whole service stops working.
Redundancy is the foundation, supported by timeouts, retries, and circuit breakers.
21Hexagonal Architecture: Hexagonal architecture is a way of structuring software so the core business logic talks to the outside world only through ports and swappable adapters.
Business logic sits at the center and knows nothing about frameworks or databases.
Ports are interfaces defined by the core; adapters implement them for specific technologies.
All dependencies point inward toward the core.
22High Availability: High availability is the ability of a system to stay operational nearly all the time, mainly by removing single points of failure through redundancy.
High availability means a system stays operational for a very high percentage of time.
Availability is often expressed in nines, such as 99.9% or 99.99%.
Redundancy, load balancing, replication, health checks, and failover remove single points of failure.
23Horizontal Scaling: Horizontal scaling (scaling out) increases a system's capacity by adding machines and spreading the work across them, rather than making one machine bigger.
Horizontal scaling adds more machines and spreads the load.
A load balancer and autoscaling distribute traffic across instances.
It brings near-unlimited growth, fault tolerance and rolling upgrades.
24KISS PrincipleKeep It Simple, Stupid: The KISS principle is a design guideline stating that systems work best when kept as simple as possible, so developers should avoid unnecessary complexity.
KISS stands for keep it simple, stupid.
Prefer the most straightforward solution that meets the real requirements.
Readable code beats clever code, and fewer moving parts mean fewer failures.
25Layered Architecture: Layered architecture splits an application into horizontal layers, such as presentation, business logic, and data access, each calling only the layer below it.
Code is split into horizontal layers such as presentation, business logic, and data access.
Each layer depends only on the layer below it.
Layers make responsibilities clear and let parts change independently.
26Loose Coupling: Loose coupling is a design principle in which components depend on each other as little as possible, so one can change without breaking the others.
Coupling measures how much one component depends on another's details.
Loosely coupled parts can be changed, tested, and deployed more independently.
Interfaces, dependency injection, APIs, and events reduce coupling.
27Microservices: Microservices are an architectural style where an application is split into small, independently deployable services that communicate over a network.
Each microservice handles one business capability and is deployed independently.
Services communicate over the network through APIs or messages.
Each service usually owns its own data.
28Monolith: A monolith is a software application built and deployed as a single unit, where all features share one codebase, one process, and usually one database.
A monolith is built, deployed, and scaled as a single unit.
It is simple to develop, test, and deploy, especially early on.
Large, poorly structured monoliths can become hard to change.
29MVCModel–View–Controller: MVC is an architectural pattern that splits an application into a Model for data and logic, a View for display, and a Controller that handles user input.
Model: the data and business logic.
View: what the user sees.
Controller: handles input and connects the model and the view.
30MVVMModel-View-ViewModel: MVVM (Model-View-ViewModel) is a UI pattern where a ViewModel holds a screen's state and actions and the View binds to it, so the UI follows state changes.
MVVM splits a screen into Model, View and ViewModel.
The ViewModel exposes the state and commands the View needs.
Data binding updates the View automatically when state changes.
31Observer Pattern: The observer pattern is a behavioral design pattern in which an object, the subject, automatically notifies a list of subscribers whenever its state changes.
A subject notifies all its registered observers when its state changes.
Observers can subscribe and unsubscribe at run time.
It decouples the code that triggers an event from the code that reacts to it.
32Peer-to-PeerP2P: Peer-to-peer (P2P) is a network design in which peers connect and share resources directly, each acting as both client and server, with no central server.
In P2P, peers share resources directly, acting as client and server.
Capacity grows as more peers join, unlike a single central server.
Discovery uses trackers or distributed hash tables; NAT needs special handling.
33Refactoring: Refactoring is the process of restructuring existing code to make it cleaner and easier to maintain without changing what the code does from the outside.
Refactoring changes the structure of code, not its behavior.
Work in small steps and run the tests after each one.
Common refactorings include renaming, extracting functions, and removing duplication.
34Repository Pattern: The repository pattern hides data access behind a collection-like interface, so business code can load and save objects without knowing where they are stored.
A repository gives business code a collection-like interface for loading and saving objects.
Its methods use domain language, such as findOverdueInvoices, not database terms.
Production code can use a database implementation, while tests use an in-memory one.
35Saga Pattern: The saga pattern runs a transaction spanning several services as a sequence of local steps, undoing completed steps with compensating actions if one fails.
A saga splits a cross-service transaction into local steps that commit independently.
If a step fails, compensating transactions undo the earlier steps in reverse order.
Orchestration uses a central coordinator; choreography uses events between services.
36Scalability: Scalability 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.
Scalability is the ability to handle more load by adding resources.
Vertical scaling (scaling up) adds power to one machine and has a hard limit.
Horizontal scaling (scaling out) adds more machines and usually requires stateless services.
37Separation of Concerns: Separation of concerns is a design principle that divides a program into distinct parts, each responsible for one clearly defined aspect of its behavior.
Each part of a program should handle one concern, or responsibility.
It makes code easier to understand, test, change, and reuse.
It applies at every level: functions, modules, layers, and services.
38Service Discovery: Service discovery is how services in a distributed system find the current addresses of other services, which change as instances start, stop and move.
Service discovery finds the current addresses of other services.
A registry such as Consul or etcd tracks healthy instances by name.
Client-side discovery picks instances in the caller; server-side uses a router.
39Service-Oriented Architecture: Service-oriented architecture builds enterprise software from reusable, network-accessible services that communicate with each other through standard contracts.
SOA builds systems from reusable services that communicate over a network through contracts.
Classic SOA used SOAP, WSDL, and a central enterprise service bus.
Its main goals are enterprise-wide reuse and integration of existing systems.
40Sidecar Pattern: The sidecar pattern runs a helper process next to an application, sharing its lifecycle and network, to add features such as logging, proxying or security.
A sidecar is a helper process deployed next to an application, sharing its lifecycle.
It adds supporting features, such as logging or proxying, without changing the application.
In Kubernetes, a sidecar is another container in the same pod.
41Singleton Pattern: The singleton pattern is a creational design pattern that ensures a class has only one instance and provides a single, global point of access to it.
A singleton class has exactly one instance with a global access point.
It is typically built with a private constructor and a static getInstance() method.
In JavaScript, an object exported from a module behaves like a singleton.
42SOLIDSingle Responsibility, Open–Closed, Liskov Substitution, Interface Segregation, Dependency Inversion: SOLID is a set of five object-oriented design principles that help developers write code that is easier to understand, extend, test, and maintain.
S: Single Responsibility, one reason to change.
O: Open–Closed, extend behavior without editing existing code.
L: Liskov Substitution, subclasses must be safely interchangeable with their parents.
43Strangler Fig Pattern: The strangler fig pattern is a way to replace a legacy system gradually by routing features to new code one at a time until the old system can be retired.
Replace a legacy system gradually, one feature at a time, instead of in a single rewrite.
A routing layer, such as a proxy or API gateway, decides which system handles each request.
Each migrated piece delivers value early and can be rolled back on its own.
44Strategy Pattern: The strategy pattern is a behavioral design pattern that puts interchangeable algorithms behind one interface, so code can switch between them at run time.
The strategy pattern puts interchangeable algorithms behind a shared interface.
The context uses a strategy without knowing which concrete one it has.
It replaces long conditional blocks and makes new options easy to add.
45Technical Debt: Technical debt is the future cost of extra work created when developers choose a quick or limited solution now instead of a better approach that takes longer.
Technical debt is the future cost of shortcuts taken today.
Its interest is the extra effort every future change requires.
Deliberate, tracked debt can be a reasonable trade-off.
46Twelve-Factor App: A twelve-factor app is a web application built according to twelve practices that make it portable, easy to deploy, and simple to scale in the cloud.
Twelve-factor is a methodology for building portable, cloud-ready web apps.
Configuration lives in the environment, not in the code.
Processes are stateless; persistent data lives in backing services such as databases.
47Vertical Scaling: Vertical scaling (scaling up) increases a system's capacity by giving a single machine more CPU, memory or faster storage, instead of adding more machines.
Vertical scaling gives one machine more CPU, memory or faster storage.
It needs no code changes and is the simplest way to grow.
It suits systems that are hard to split, such as relational databases.
48YAGNIYou Aren't Gonna Need It: YAGNI is a principle from extreme programming that says not to build a feature or abstraction until you actually need it, rather than because you might later.
YAGNI stands for you aren't gonna need it.
Build features and abstractions when they are needed, not when they are imagined.
Speculative code costs time now and maintenance later, and it often guesses wrong.