Monolith

Recall WordPress from Chapter 1. WordPress has to let people write, edit, publish, and organize content. A site owner needs posts and pages, drafts and scheduled publication, media, comments, revisions, and control over who could read or change each item. A public request has to find the requested content, apply the site’s presentation, and return a web page.

Site owners also want different layouts, navigation, search behavior, forms, analytics, commerce features, and integrations. They want to add those differences without rebuilding them after every WordPress upgrade. The software has to work on hosting that its maintainers do not control, remain approachable for non-specialists, and still let developers alter much of a site’s behavior.

A small, integrated application is easy to distribute, but varied uses need extension points. WordPress’s architecture developed around that tension.

A conventional WordPress installation is an integrated PHP application. Its package contains WordPress Core. The installation also contains a configuration, active plugins, and one selected theme. It uses a database for content and configuration, and it uses files or object storage for media and other assets.

For a traditional page request, a web server invokes WordPress. Core loads the active plugins, determines which content and template are needed, reads the necessary data, and lets the theme generate the response. The browser receives the resulting HTML.

%%{init: {'sequence': {'mirrorActors': false}}}%%
sequenceDiagram
    actor Browser

    box WordPress (one deployment boundary)
        participant Core as WordPress Core
        participant Plugins as Active plugins
        participant Theme as Selected theme
    end

    participant Database
    participant Files as Media and files

    Browser->>Core: Request a page
    Core->>Plugins: Run active plugins
    Core->>Database: Read content and configuration
    Database-->>Core: Rows
    Core->>Files: Read media
    Files-->>Core: Asset
    Core->>Theme: Render with selected theme
    Theme-->>Core: HTML
    Core-->>Browser: Response

The arrows do not mean that every request follows exactly the same sequence. A cache may answer before PHP runs. A plugin may intercept a request or add another data source. A theme may make several queries while rendering a page. The important point is the application boundary: Core, plugins, and the theme normally participate in the same PHP application and are released to a site as parts of the same installation. The database and the media storage sit outside that boundary because they are not part of what gets packaged and released with WordPress, not because they must run on separate hardware. A small installation often runs the database on the same machine as WordPress itself.

This is a monolith in the architectural sense. The main application is deployed as one unit.

The word monolith comes from the idea of something made from a single piece of material, such as a building carved, cast, or excavated from one block of rock.

In software, monolithic architecture is a traditional design in which the user interface, business logic, and database access run as one application. They may be organized into many parts, but they often share one codebase and are always deployed together. A monolith is therefore an application with one deployment boundary.

To deploy software is to put a version of it into operation so people can use it. For WordPress, we can rent a server: one machine that people can reach over a network. That machine runs WordPress: its core, plugins, theme, and configuration, deployed together as one unit.

Monolithic architecture is not the only way to structure and deploy a software system. A software system can contain multiple components that are deployed independently. Users may still experience that system as one application. Later lectures cover other architectures, including microservices, where a system is deliberately split into components that are deployed and scaled on their own. We start with the monolith because it is the simplest deployment boundary to reason about.

HopPress, the CMS from Chapter 1, is also a monolith. So is CourseTracker from Chapter 2. Imagine the university approves each application’s initial release. Each is one deployable application running as a single unit. The university now needs a place to run them.