Overengineering: Causes, Symptoms and Treatment
summary
Microservices become overengineering when teams split systems without data and build features no one uses: a banking PDF pipeline adds a WebSockets streaming API and extra services to show progress, but users only wait two seconds so updates go unseen. Use UX analytics, performance metrics, documented use cases and source-code mining (git pull‑request co-change) to find hotspots, extract one service at a time, add CI/deployment automation, prefer read-models/CQRS for complex persistence, and do a clear cost–benefit before splitting.
AI-written summary · about
chapters (9)
- 0:00Introduction and speaker
- 1:51What is over-engineering
- 2:34Ignoring usage data
- 7:30Data-driven design
- 11:27Microservices too early
- 13:37The dangers of rewrites
- 16:33Monolith to microservices pitfalls
- 21:48Cost-benefit analysis
- 25:23Q&A session
related talks
55mMicroservices, Where Did It All Go Wrong
57mEmbracing Microservices
43mPanel: Microservices, Where Did It All Go Wrong
20m3 reasons why micro-services aren't the miracle cure
46mSurviving microservices
44mMicroservices, Where Did It All Go Wrong
01h 00mMicroservices, Where Did It All Go Wrong?
38mMicroservices, a bittersweet symphony