Software Architecture
General material on the engineering underneath an architecture.
4 to work through
-
advanced
A commerce platform runs a very large monolith serving enormous traffic and chooses not to decompose it into microservices. What must be true for that to be the right choice?
2 min answer -
advanced
Knight Capital lost roughly $460M in 45 minutes in 2012 after a deployment reached seven of eight servers. Which architectural failures made that possible, and which one would you fix first?
2 min answer -
advanced
Uber reached roughly 2,200 microservices and found the estate incomprehensible. Their fix was not consolidation. What was it, and why does it generalise?
2 min answer -
advanced
You need to ship a rewrite of the pricing engine. Same inputs, same expected outputs, completely new implementation. How do you release it?
2 min answer
10 terms in this topic
Architectural Significance
The test that separates decisions worth reviewing from the ones a team should make alone, by asking what undoing each one would cost rather than how …
practiceDomain-Driven Design
Modelling software around the business domain, with boundaries drawn where the language of the business changes.
case-studyEtsy's Continuous Deployment
Etsy moved from infrequent, risky releases to dozens of deploys a day, demonstrating that deployment frequency and stability improve together rather …
patternMicroservices
An architectural style where an application is a set of independently deployable services, each owning its data and aligned to a business capability.
case-studyMonzo's Microservice Estate
Monzo runs a bank on well over a thousand microservices, and the interesting engineering is in the platform and network isolation that makes that num…
practiceRefactoring
Changing the internal structure of code without changing its external behaviour, in small verified steps.
conceptService Boundary
The line separating what one service owns and is accountable for from what it must ask another service about.
practiceSOLID
Five object-oriented design principles — single responsibility, open/closed, Liskov substitution, interface segregation, dependency inversion.
conceptTechnical Debt
The future cost incurred by choosing an expedient implementation now instead of the better one.
case-studyUber's Domain-Oriented Microservice Architecture
After growing to roughly 2,200 microservices, Uber grouped them into domains behind gateways with strict dependency layering, to recover the comprehe…
Neighbouring topics
SOLID
Five design principles, two of which scale beyond the class.
Domain-Driven Design
Ubiquitous language, bounded contexts and context mapping.
Bounded Contexts
Where one model ends and another begins, and why forcing one fails.
Clean Architecture
Concentric layers with dependencies pointing only inwards.
Hexagonal Architecture
Ports defined by the domain, adapters supplied by infrastructure.
Microservices
Independent deployability, and the distributed problems it buys.
Modular Monolith
Enforced internal boundaries without a network between them.
Service Boundaries
Drawing lines along change patterns rather than technical layers.
Design Patterns
Reusable solutions at code level, and when they become ceremony.
Refactoring
Changing structure without changing behaviour, in verified steps.
Technical Debt
Deliberate, tracked and repaid — as distinct from mess.
Testing Strategies
The pyramid, and the contract tests distributed systems add to it.
Contract Tests
Capturing what consumers actually use, not what the API documents.
CI/CD
Continuous integration and delivery, and the architecture that caps them.
Release Strategies
Blue-green, canary, shadow and progressive delivery.
Feature Flags
Decoupling deploy from release, with an expiry date.
Trunk-Based Development
Short-lived branches, and unmerged work as inventory.
Code Review
Where architectural rules are enforced by people rather than by tools.
DORA Metrics
Throughput and stability moving together rather than trading off.