IT Architecture : All your micro-services are wrong PERIOD!
summary
Argues that common microservice designs create distributed monoliths and shows a concrete fix: a demo with Customer and Deposit services, databases, and a React micro‑frontend where moving the deposit_limit from Customer into Deposit removes a runtime RPC, prevents outages, and lets Deposit enforce consistency. Uses Theory of Constraints, Reverse Conway’s Law, DDD and capability thinking, replaces cross‑service sync with local persistence, and claims this enables 20–30 initiatives per quarter and microfrontends with degraded UX as a graceful fallback.
AI-written summary · about
chapters (13)
- 0:00Introduction
- 2:07Why microservices are wrong
- 4:14Flawed microservices design
- 7:20Live coding the setup
- 16:29Catastrophic failure scenario
- 19:00Root cause analysis
- 21:08Data ownership dependencies
- 24:45Entry requirements technique
- 27:56Redesigning architecture
- 31:09Implementing solution
- 37:13Demonstrating fixed system
- 43:17Business autonomy
- 47:06Q&A
related talks
55mMicroservices, Where Did It All Go Wrong
52mWhat Does a Good Microservice Architecture Look Like?
49mMicroservices guided by DDD and reactive systems paradigm
36mDo Proper Monoliths before You Do Microservices!
43mHow to Avoid Doing Microservices Completely Wrong
52mI Have a Microservices Architecture and I Didn't Know.
43mPanel: Microservices, Where Did It All Go Wrong
44mMicroservices, Where Did It All Go Wrong