Modular Monolith and the Prisoner of Microdisservices
summary
Claims that a modular monolith often beats premature microservices are illustrated with concrete numbers and tools: 30 years of experience, 99% of production sport‑tech platform built on plain ASP.NET, kickoff mid‑September and first tournament live 3 January, typical load ~10 concurrent users, live score updates every 30–40 seconds. Architecture uses logical decomposition so teams deploy as a monolith first and split later, avoiding Kubernetes/autoscaling pain while keeping statelessness and autoscaling as options; microservices remain an infrastructure decision.
AI-written summary · about
chapters (17)
- 0:00🚀 Build Stuff Conference – Get Your Tickets!
- 1:20Introduction: Why Microservices Aren't Always the Answer
- 4:15The Rise of Modular Monoliths
- 7:30The Evolution of Software Architecture
- 10:00Key Challenges in Microservices Architecture
- 13:45Benefits and Drawbacks of Microservices
- 17:30Microservices and Agility: The Myth of Parallel Development
- 20:50Statelessness and Scalability in Microservices
- 24:10Fault Tolerance in Microservices vs Monoliths
- 27:00The Operational Overhead of Microservices
- 30:00The Truth About Service Coordination and Distributed Transactions
- 33:20How Microservices Impact Data Management
- 36:00Case Study: Building Modular Monoliths in Sport-Tech
- 40:20The Transition from Monoliths to Microservices
- 43:10The Role of Logical Decomposition in Software Design
- 46:20Serverless and the Granularity of Functions
- 51:13Conclusion: The Future of Software Architecture
related talks
01h 04mModular Monoliths and Other Facepalms
01h 01mModular Monolith Instead of Microservices: How, When and Why
43mModular Monoliths: The Architecture That Scales w Your Domain
47mMicroservices? Monoliths? An Annoying Discussion!
55mArchitectural Patterns for Rapid, Reliable, Frequent and Sustainable Development
23mMicroservices within a Monolith
59mMajestic Modular Monoliths
06mDo proper monoliths before you do microservices!