Monolithic Delivery
summary
Argues that the real problem is monolithic delivery not monolithic code, illustrated by a finance scheduler that hits memory at a million trades and by a retail loyalty feature built incrementally: a .NET REST API, NoSQL documents, added a join flag, quick database locks to let a handful of users share points, then tracked migration and scaling concerns. Recommends small changes (around half a day to a day), runtime feature toggles, frequent deploys, automated tests and monitoring; prototypes work but require disciplined refactoring and rollback planning.
AI-written summary · about
chapters (14)
- 0:00Introduction
- 6:56Process Design
- 9:03Systems
- 10:51Micra Services
- 12:03Premise
- 14:15Background
- 14:44Principle Takeaway
- 20:33Example
- 28:58Emergency Design
- 31:56Ralph Johnson
- 51:40Refactoring
- 54:56Deployment
- 56:33Feedback
- 58:36Questions
related talks
55mArchitectural Patterns for Rapid, Reliable, Frequent and Sustainable Development
48mMicroservices vs The Distributed Monolith
01h 01mArchitecting for rapid, frequent, reliable delivery of software.
01h 04mPractical advice for building glorious monoliths
47mMicroservices? Monoliths? An Annoying Discussion!
42mDo proper monoliths before you do microservices!
43mModular Monoliths: The Architecture That Scales w Your Domain
02mMark Richards at DDD Europe