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.

• Deploying a microservices architecture.

• Using a shared database amongst multiple user-facing apps.

The third option—sharing the database—is usually discussed as an antipattern, but as we’ll see, it’s anything but. It’s important to understand that our system architecture—even if it’s just one app—is never done. We never achieve a state of completeness where we can then stop thinking about architecture. Rather, the architecture changes and evolves as time goes by. It must respond to the realities we face, not drive toward some idealistic end state. 

So, we strongly encourage you to understand monolithic architectures, microservices, and shared databases as techniques to apply if the situation calls for it. It’s also worth understanding that any discussion of what a system’s architecture is has to be discussed in a context. It’s entirely possible to have 100 developers working on 30 apps, some of which are monolithic. within a given context.

Let’s start with monolithic architectures.         

Monoliths get a bad reputation 

If we have a single app, we have a monolithic architecture. In other words, a monolithic architecture is one where all functions reside in one app that’s built, tested, and deployed together.

When a team is small and when an app is new, a monolith has an extremely low opportunity cost for new features as well as ...