Design Trade-offs in Modern Architectures
summary
Argues that architecture is choosing tradeoffs not following mantras: you cannot get unlimited performance and scale cheaply, CAP means pick two, and most teams misunderstand microservices (claims like “80% aren’t really microservices”). Gives concrete pain: a shared database with a table of 800 columns that forces 15‑year cadence changes and kills agility — shared database = poor encapsulation. Recommends export your data via APIs and design for adequate performance, not maximal speed.
AI-written summary · about
chapters (23)
- 0:00Introduction
- 1:28Nonfunctional Requirements
- 3:39Characteristics
- 7:25Software
- 10:27Which car should I buy
- 11:56Is the performance adequate
- 15:23High scale or high performance
- 16:22Cap Theorem
- 24:32Modern Architecture
- 26:30Monolith vs Distributed Architecture
- 29:03Distributed vs Monolith
- 31:37Microservices
- 34:08Misconceptions about microservices
- 36:04The micro in microservices
- 40:12Unified data model
- 42:00Dont screw up
- 43:26Dry vs Reuse
- 45:33Shared database vs poor encapsulation
- 46:49High coupling vs low coupling
- 48:44Evaluating tradeoffs
- 50:57Embrace change
- 53:37Work from the business
- 56:01Conflicting characteristics
related talks
50mTowards an Evolutionary Architecture
45mArchitecture: The Stuff That's Hard to Change
41mArchitecture and Agility: A Shared Skillset!
46mDigital scale-up architectural patterns
42mPanel Discussion: Architecture
01h 01mArchitecture: The Stuff That's Hard to Change
51mA Contrarian View of Software Architecture
24mThe too many faces of Architecture