> Am I the only one that loves the monolith? Discussions on this topic are typically mired by a lack of conceptual clarity†. Are we describing a monolith in te

> Am I the only one that loves the monolith? Discussions on this topic are typically mired by a lack of conceptual clarity†. Are we describing a monolith in terms of the process model, or the deployment model? In context of scale-up/scale-out concerns, we would be considering the deployment model. In context of loose-coupling and extensibility, we would be considering the process model. Postgres is a classic example. [1] [edit: note above are not mutually exclusive.] Naturally, an increase in the number of moving parts places additional orthogonal demands in terms of operational integrity. As with any upward clicks of complexity, the decisions should be informed by valid‡ requirements and facts. Ok, done with my mini rant /g. As to your query, in certain cases a monolith is indeed worthy of love. [1]: http://raghavt.blogspot.com/2011/04/postgresql-90-architecture.html http://raghavt.blogspot.com/2011/04/postgresql-90-architectu... † Not a surprise in a field celebrating its unique brand of "senior engineers with 3 years of experience"... ‡ No, hype cycles are not valid architectural and/or business requirements.