Solving technical debt of a microservices architecture
summary
Microservices proliferate into dozens of tiny services (PDF-per-type, one-off tax endpoints) causing repeated DTO mapping and confusion; team size is ~12–15 and ownership moves to team-owned bounded contexts after a failed attempt at a single shared data model. Tools: Node, Go, C#, MySQL/Redis/Elasticsearch, Jenkins + Octopus, Git; fixes include moved all code to Git, collapsing unnecessary service layers to remove mapping, colocating performance-coupled services on the same VM, shifting to event-driven keys and a 24/7 telepresence setup to recover velocity and clarity.
AI-written summary · about
chapters (9)
- 0:00Introduction and team backgrounds
- 14:56Startup vs corporate differences
- 17:44What is technical debt
- 20:46Microservices architecture issues
- 27:59Mapping problems in services
- 32:18Domain boundaries and subdomains
- 36:24Single data model challenges
- 41:47Solutions and refactoring
- 45:02Q&A and flat architecture
related talks
48mIT Architecture : All your micro-services are wrong PERIOD!
44mMicroservices - How to create problems by solving problems?
51mBig microservices, small team a painful story
48mThirty months of microservices
46mWhy Cross-Functional Teams Build Better Microservices
15mDo's and Dont's moving to Golang Microservice Architecture
01h 01mMicroservices Gone Wrong
52mWhat Does a Good Microservice Architecture Look Like?