From the early days of information technology and the advent of computing power to speed up computational tasks, the preferred design pattern for an application was monolithic. Simply put, a monolithic design pattern is one in which all aspects of the system are self-contained and independent from other systems or processes. This pattern worked great with the large mainframe monoliths that existed and allowed for the code logic, storage devices, and printing to all be done in the same location. Networking, as we know it today, was not possible and what little connectivity was available was significantly slower, preventing additional systems from being interconnected. As new business requirements were identified, they were designed directly in the existing monolith, making them critical and very tightly coupled. Ultimately, monolithic design patterns enabled all tasks to be executed to complete a desirable outcome.

As technology advanced and the needs of computational power were evolving, system designers found that adding new functionality into a monolith was cumbersome and potentially introduced hard-to-identify bugs. They also realized that reusing components and tasks was a great way to save time, money, and reduce code change bugs. This modular approach to systems design, which was still mostly monolithic, enabled reuse and allowed for more targeted maintenance updates to take place without impacting the entire application or system. This philosophy continued to evolve as technology advanced and allowed for the splitting apart of some of the largest monoliths into separate discrete subsystems, which could then be updated independently. This concept of decoupling components is a key driving factor into the evolution of system designs and will continue to get more and more discrete as technology advances.