Software Architecture
General material on the engineering underneath an architecture.
3 to work through
-
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
18 terms in this topic
Blue-Green Deployment
Running two identical production environments and switching traffic from the old one to the new one in a single cut, with the old kept warm for rollback.
patternCanary Release
Routing a small fraction of traffic to a new version, watching its metrics, and expanding or rolling back based on what they show.
practiceCI/CD
Merging work continuously into a shared trunk with automated verification, and keeping every commit in a state that could be released.
patternClean Architecture
Concentric layers with a strict dependency rule — source code dependencies point only inwards, towards higher-level policy.
conceptCognitive Load
The total amount a team must hold in its head to work effectively, and a real constraint on how many services or domains one team can own.
practiceDomain-Driven Design
Modelling software around the business domain, with boundaries drawn where the language of the business changes.
metricDORA Metrics
Four measures of software delivery performance — deployment frequency, lead time for change, change failure rate, and time to restore service.
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 …
patternFeature Flag
A runtime switch that decouples deploying code from releasing behaviour, so unfinished or risky work can ship dark.
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.
practiceTest Pyramid
A distribution of tests weighted towards many fast unit tests, fewer integration tests, and very few slow end-to-end tests.
practiceTrunk-Based Development
All developers integrating small changes into a single shared branch at least daily, with long-lived branches avoided entirely.
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.
No content yetDomain-Driven Design
Ubiquitous language, bounded contexts and context mapping.
No content yetBounded Contexts
Where one model ends and another begins, and why forcing one fails.
No content yetClean Architecture
Concentric layers with dependencies pointing only inwards.
No content yetHexagonal Architecture
Ports defined by the domain, adapters supplied by infrastructure.
No content yetMicroservices
Independent deployability, and the distributed problems it buys.
No content yetModular Monolith
Enforced internal boundaries without a network between them.
No content yetService Boundaries
Drawing lines along change patterns rather than technical layers.
No content yetDesign Patterns
Reusable solutions at code level, and when they become ceremony.
No content yetRefactoring
Changing structure without changing behaviour, in verified steps.
No content yetTechnical Debt
Deliberate, tracked and repaid — as distinct from mess.
No content yetTesting Strategies
The pyramid, and the contract tests distributed systems add to it.
No content yetContract Tests
Capturing what consumers actually use, not what the API documents.
No content yetCI/CD
Continuous integration and delivery, and the architecture that caps them.
No content yetRelease Strategies
Blue-green, canary, shadow and progressive delivery.
Feature Flags
Decoupling deploy from release, with an expiry date.
No content yetTrunk-Based Development
Short-lived branches, and unmerged work as inventory.
No content yetCode Review
Where architectural rules are enforced by people rather than by tools.
No content yetDORA Metrics
Throughput and stability moving together rather than trading off.
No content yet