Monolithic Architecture

Monolithic architecture is an application design in which core business capabilities are packaged and deployed together. An online store, for example, might include product browsing, shopping cart management, checkout, and order administration in one application executable or deployment package. These capabilities usually interact through in-process function or method calls rather than independently deployed network services. The defining characteristic is the deployment boundary, not the number of source files, servers, or database tables.

A monolith can still have a well-structured internal design. Engineers can separate presentation, business logic, and persistence into modules with explicit interfaces and controlled dependencies. This makes the application easier to test and change without introducing distributed communication. A shared relational database is common and can simplify transactions spanning several business operations, but a monolith does not require one database. Likewise, using separate frontend assets or external managed services does not automatically turn its core application into microservices.

In the cloud, a monolith can run on virtual machines, a managed application platform, or containers. For example, a team can package an entire order-management application into one container image and run multiple identical replicas behind a load balancer. Each replica contains the same business capabilities. Containerization changes packaging and execution; it does not by itself change the application architecture.

Monoliths can scale horizontally as well as vertically. Horizontal scaling works best when request handlers do not depend on local session state or local files that other replicas cannot access. Sessions, uploaded objects, and durable records can be stored externally. Nevertheless, if only the reporting component needs additional CPU capacity, scaling identical application replicas also provisions the checkout and catalog code. A shared database can become a bottleneck even when application capacity increases.

The principal advantages are fewer network boundaries, a simpler deployment topology, straightforward local development, and easier coordination of transactions within one database. For a small team building a cohesive application, these properties can reduce operational work. The trade-offs become more visible as the system grows: changes share a release cycle, dependency upgrades can affect unrelated modules, and a memory leak or resource-intensive operation can impair other functionality in the same process. Strong module boundaries and automated regression tests help control these risks.

Deployment strategy remains an operational choice. A monolith can use rolling deployments or blue/green deployments instead of accepting downtime for every release. During a rolling deployment, old and new versions may run simultaneously, so database migrations and interfaces must remain compatible. Application rollback also needs to account for data changes; restoring an earlier executable does not automatically reverse a schema migration.

For architectural-pattern questions, distinguish independent deployment from internal modularity. Microservices place capabilities behind separately deployable service boundaries, introducing network calls and additional distributed-systems concerns. Event-driven communication, fanout, orchestration, and choreography describe interactions or workflow coordination and are not exclusively alternatives to monolithic packaging. A monolith can publish events or participate in an orchestrated workflow while remaining one deployable application. Choose the architecture from requirements such as release independence, scaling needs, transaction boundaries, team ownership, and operational capacity, rather than assuming microservices are always preferable.