Monoliths, Microservices, and Shared Databases

There wasn’t an easy way to put this into the course, but because we discussed APIs in the “API Endpoints” lesson, there is an implicit assumption that we might have more than one Rails app someday, so we want to spend this appendix talking about that briefly.

When a team is small, and we have only one app, whether we know it or not, we have a monolithic architecture. A monolithic architecture has a lot of advantages. Starting a new app this way has a very low opportunity cost, and the carrying cost of a monolithic architecture is quite low for quite a while.

The problems start when the team grows to an inflection point. It’s hard to know what this point is, as it depends highly on the team members, the scope of work, the change in the business and team, and what everyone is working on. Most teams notice this inflection point months—sometimes years—after they cross it. Even if we know the day we hit it, we still have some decisions to make. Namely, do we carry on with a monolithic architecture? If not, what are the alternatives, and how do we implement them?

In this section, we want to try to break down the opportunity and carrying costs of:      

• Staying with a monolithic architecture. ...