Monoliths vs Microservices is Missing the Point—Start with Team Cognitive Load
summary
Argues organizations should size services to team cognitive load instead of choosing monolith vs microservices, defines intrinsic/extraneous/germane load, and uses concrete practices—domain‑driven design, mobbing, developer experience work, and a finished viable platform—to reduce extraneous load. Recommends teams ~<9 people and four team types (including stream-aligned team and platform/enabling/complicated‑subsystem). Case studies: a retailer splits a growing monolith into market-aligned teams and platform services and speeds delivery; an engineering‑productivity team breaks into domain teams and raises motivation. Surveys (1–5) measure understanding; aligns decisions to Accelerate’s four metrics.
AI-written summary · about
chapters (12)
- 0:00Start
- 1:51"Start with monolith and extract microservices." - Tammer Saleh
- 2:04"If you can't build a monolith, what makes you think microservices are the answer?" - Simon Brown
- 2:564 key metrics: 'Accelerate' lead time deployment frequency mean time to restore (MTTR) change fail percentage
- 4:37Software that is 'too big for our heads' works against organizational agility
- 9:00Software that fits in our heads
- 10:48Whole-team techniques (mobbing)
- 11:02Well-chosen domain boundaries (DDD)
- 12:04Thinnest Viable Platform (TVP)
- 13:45Stream-aligned team Enabling team Complicated Subsystem team
- 18:23Case Studies
- 30:04Getting started with team cognitive load
related talks
06mDo proper monoliths before you do microservices!
47mMicroservices? Monoliths? An Annoying Discussion!
13mYou're not Netflix (Microservices, Monolith architecture)
40mMonolith Explosion into Multidisciplinary Teams
38mMonolith vs. Microservices
36mThe human factor you might be missing when designing your system
51mTeam Cognitive Load as a metric to measure Platform impact
47mMicroservices and the Inverse Conway Manoeuvre