▲ 7 ▼ The Decomposable monolith

This is an idea I’ve been kicking around for a little while, and I’m curious what others think about it. Everyone seems to be talking about microservices these days, but in most projects there is a transition point from monolith to service-based designs. I contend that for new projects you should almost always start with a monolith. I said it seven years ago when I wrote about Service Oriented Design with Ruby: if there’s any way you can avoid services, build a monolith. However, making the shift to services later can be quite tricky, so in this post I’ll explore the advantages of a monolith while proposing a way to structure a new project that lends itself to being broken out into services later. I call this design/architecture pattern The Decomposable Monolith. To help illustrate the idea, we’ll work through an example using Go as the implementation language and a next-generation data platform (say for time series data) as the application.