Distributed Monoliths

As part of developing RESTful HTTP APIs at work, there’s been a lot of discussion over the “best” way to architect/implement everything. To avoid relying strictly on my own instincts and relearning mistakes that many others have already learned from, I’ve been reading O’Reilly’s Building Microservices. I haven’t finished it yet, but have gotten a lot out of what I’ve read so far (and been pleased to see that my instincts have been largely supported by someone who’s experienced implementing such systems).

The chapter on Integration presents the idea of “the shared database” [p. 41, 1] as possibly the most common and seemingly simple form of integration between different services. You’ve split your environment into multiple applications/services, but decided the way they should operate on shared data is by hooking directly into the same database. I found this section especially interesting because this approach has been championed by some around the office, but I had strong concerns about it and many of those were highlighted in the book.

1. The database schema becomes a large shared API. Any schema changes you want to make (e.g., improved data representation, new logic in one service requires table changes, etc) now requires careful planning and regression testing to avoid breaking any of the services that interact with the database.
2. You’ve lost loose coupling between your services because you can no longer change implementation details (e.g., moving from an RDBMS to a NoSQL system) because every consumer that interacts with it is tightly coupled to those low-level implementation details. This can also introduce restrictions on the technology choices for consumers since they’ll be limited to options that have the required driver support.
3. Major DRY violations / loss of cohesion. Logic associated with interacting with the data in the database is now spread across every consumer. You’re forced to replicate code and have to remember to update it everywhere, which is likely to be an error prone process.

After thinking about it, I decided this approach is effectively building a distributed monolith. As with most clever things I think up, I’m not the first to coin this term and a quick Googling turns up a handful of unique sources. Oddly enough, one was posted the same day I wrote this post. At least it was close to having a novel thought. Oldest reference I could find dates back ~7 months to November 2014. Oh well. At least it wasn’t yet another thing everyone’s excited they “invented” that IBM had already done back in the 1960s (and everyone promptly forgot about).

1: Sam Newman. Building Microservices. O’Reilly Media, 2015.