Recommended Readings on When to Break Down a Monolith: Experiences and Insights from Shopify and Other Companies

This message was imported from the Ruby/Rails Modularity Slack server. Find more info in the import thread.

Message originally sent by slack user U782WI24OVK

:wave: I’d like to surface <@U78HE411QT1>’s question here and expand a bit:

Are there some seminal write-ups you’d recommend on when it makes sense to start breaking down the monolith?
In my own experience, it starts making sense when a monolith as grown to a point where:

  • Running the entire test suite is so slow that degrades productivity.
  • Making a change in one place breaks other places that aren’t supposed to be related.
  • Development teams stumble upon each other while code reviewing or merging PRs.
  • Lack of enforced boundaries leads to cognitive overload across the entire monolith.

Two articles that go deeper on these topics and explain it very well are:

I’d love to hear other companies thoughts on this :slightly_smiling_face:

Message originally sent by slack user U78EKGG059M

That pretty well sums up the reasons we outlined when we took on the project at Root Insurance. We owe the community two blog posts. One on our tooling used to monitor boundary progress and two on our conversion and outcomes.

Mh aren’t those indicators that it might be too late?

Especially the test suite one

Message originally sent by slack user U78EKGG059M

Define “too late”, its never too late - it might be overdue but better late than never. Its also hard to get organizational buy-in without pointing to wins/positive outcomes

Message originally sent by slack user U782WI24OVK

Mh aren’t those indicators that it might be too late?

At least in my experience, it’s always been too late :smile: