Application Architectures

Before we can appreciate the complexity and trade-offs of modern distributed architectures, we must thoroughly understand where software architecture began: the monolithic application. Far from being an outdated relic, monolithic architecture remains the foundation upon which billions of applications run today, and understanding its principles is essential for any engineer working at the application layer of computer networks.

The term monolith derives from the Greek monolithos—meaning 'single stone.' In software architecture, it refers to an application designed as a unified, indivisible unit where all components—user interface, business logic, data access, and service layers—are tightly integrated and deployed together as a single artifact.

This architectural style dominated software development for decades, and for good reason. Its simplicity, predictability, and ease of development made it the natural choice for applications of all sizes. Even today, many of the world's most mission-critical systems—from banking core systems to air traffic control—rely on monolithic architectures that have proven their reliability over decades of operation.

A monolithic application is a software system designed as a single, self-contained unit where all functional components are interconnected and interdependent, running within a single process or a tightly coupled set of processes on a single runtime environment.

Architectural Characteristics:

The defining characteristic of a monolith is its single deployable unit. Whether the application is a web server, desktop application, or enterprise system, all code is compiled, packaged, and deployed together. Changes to any component require redeploying the entire application.

Within this single unit, we typically find several distinct logical layers that organize the codebase, even though they execute within the same process:

1. Presentation Layer (User Interface) — Handles user interactions, rendering views, and presenting data. In web applications, this might be server-side templating or API endpoints serving a frontend.

2. Business Logic Layer (Application/Domain Layer) — Contains the core rules, computations, and workflows that define what the application does. This is where business requirements translate into code.

3. Data Access Layer (Persistence Layer) — Manages interactions with databases, file systems, or external storage. It abstracts the underlying data storage mechanisms from the business logic.

4. Service Layer (Integration Layer) — Orchestrates between other layers and may handle cross-cutting concerns like authentication, logging, and transaction management.

Internal Communication Patterns:

Unlike distributed systems where components communicate over the network, monolithic components communicate through in-process method calls. When the presentation layer needs data from the business logic layer, it simply invokes a function or method—there's no network serialization, no HTTP overhead, no message queues.

This communication model has profound implications:

• Latency: In-process calls execute in nanoseconds to microseconds, orders of magnitude faster than network calls (milliseconds).
• Reliability: No network partitions, timeouts, or connection failures between components.
• Transactions: ACID transactions can span multiple operations naturally since all code runs in the same process with access to the same database connection.
• Data Sharing: Objects and data structures can be passed by reference between components, avoiding serialization overhead.

From a computer networks perspective, monolithic applications present a distinctive profile. Understanding these network characteristics is essential for architects, developers, and network engineers working with these systems.

External Network Interface:

While internal communication avoids the network, monolithic applications still interact extensively with external networks:

1. Client Connections: The application receives HTTP/HTTPS requests from browsers, mobile apps, or API consumers. A single monolithic server might handle thousands of concurrent connections.

2. Database Connections: Even though the database might run on the same physical machine, communication typically occurs over TCP sockets using database-specific protocols (MySQL protocol, PostgreSQL wire protocol, etc.).

3. External Services: Integration with third-party APIs (payment processors, email services, etc.) requires outbound HTTP connections.

4. Cache Servers: If using external caching (Redis, Memcached), communication occurs over their respective protocols.

Connection Pooling and Resource Management:

Monolithic applications must carefully manage their network resources, particularly database connections. Since all application logic shares a single connection pool, resource contention can become a bottleneck:

┌─────────────────────────────────────────┐
│         Monolithic Application          │
│                                         │
│  ┌────────────────────────────────────┐ │
│  │   Database Connection Pool         │ │
│  │   (shared across all features)     │ │
│  │                                    │ │
│  │   Connection 1 ──────────────┐     │ │
│  │   Connection 2 ──────────────┼──>  │ │
│  │   Connection 3 ──────────────┤     │ │
│  │   ...                        │     │ │
│  │   Connection N ──────────────┘     │ │
│  └────────────────────────────────────┘ │
│                                         │
│    Orders Module ─────┐                 │
│    Inventory Module ──┼──> Pool        │
│    Reports Module ────┤                 │
│    Auth Module ───────┘                 │
│                                         │
└─────────────────────────────────────────┘

This shared resource model means a misbehaving feature (like a report that holds connections too long) can starve other features of database access—a phenomenon that wouldn't occur in properly isolated microservices.

Horizontal Scaling and Network Load Balancing:

When a monolithic application needs to handle more traffic, the typical approach is horizontal scaling—running multiple instances behind a load balancer:

                    ┌──────────────────┐
        Client ────>│  Load Balancer   │
       Requests     └────────┬─────────┘
                             │
           ┌─────────────────┼─────────────────┐
           │                 │                 │
           ▼                 ▼                 ▼
    ┌─────────────┐   ┌─────────────┐   ┌─────────────┐
    │ Monolith    │   │ Monolith    │   │ Monolith    │
    │ Instance 1  │   │ Instance 2  │   │ Instance 3  │
    └──────┬──────┘   └──────┬──────┘   └──────┬──────┘
           │                 │                 │
           └─────────────────┼─────────────────┘
                             │
                             ▼
                    ┌──────────────────┐
                    │    Database      │
                    │  (shared state)  │
                    └──────────────────┘

This architecture introduces network considerations:

• Session Affinity (Sticky Sessions): If the application maintains session state in memory, the load balancer must route subsequent requests from the same user to the same instance.
• Shared Database: All instances connect to the same database, potentially creating a bottleneck.
• Health Checks: The load balancer performs periodic HTTP health checks to detect failed instances.
• Connection Limits: Each instance maintains its own connection pool, so total database connections scale with instance count.

Monolithic applications can be deployed in various configurations, each with distinct network topologies and implications for reliability, performance, and operational complexity.

Single-Server Deployment:

The simplest deployment places everything—application code, web server, and database—on a single physical or virtual machine:

┌─────────────────────────────────────────────────────┐
│                  Single Server                      │
│  ┌───────────────────────────────────────────────┐  │
│  │  Web Server (Nginx/Apache)                    │  │
│  │       │                                       │  │
│  │       ▼                                       │  │
│  │  Application Runtime (Node.js/JVM/etc.)       │  │
│  │       │                                       │  │
│  │       ▼ (localhost/socket)                    │  │
│  │  Database Server (PostgreSQL/MySQL)           │  │
│  └───────────────────────────────────────────────┘  │
│                                                     │
│  Public IP: 203.0.113.100                           │
│  Ports: 80 (HTTP), 443 (HTTPS)                      │
└─────────────────────────────────────────────────────┘

Advantages:

• Minimal network latency (localhost or Unix socket communication)
• Simplified security (no network exposure for database)
• Low operational overhead

Disadvantages:

• Single point of failure
• Limited scalability
• Resource contention between application and database

Multi-Tier Deployment:

Separating the application and database onto different servers introduces network communication but improves scalability and reliability:

┌────────────────────────────────┐
│       Application Server       │
│  ┌──────────────────────────┐  │
│  │  Web Server + Application │  │
│  │          Runtime           │  │
│  └────────────┬─────────────┘  │
│               │                │
│  Public IP: 203.0.113.100      │
└───────────────┼────────────────┘
                │ TCP/5432 (PostgreSQL)
                │ Private Network
                ▼
┌────────────────────────────────┐
│         Database Server        │
│  ┌──────────────────────────┐  │
│  │    PostgreSQL Server     │  │
│  │                          │  │
│  └──────────────────────────┘  │
│  Private IP: 10.0.1.50         │
│  (not publicly accessible)     │
└────────────────────────────────┘

Network Security Considerations:

• The database server has only a private IP, inaccessible from the internet
• Firewall rules restrict database access to only the application server IP
• Communication between servers should occur on an isolated private network (VPC/VLAN)
• Consider TLS encryption for database connections if traversing untrusted networks

High-Availability Deployment:

Production monoliths often require high availability, introducing additional network complexity:

                         ┌─────────────────┐
                         │  DNS (Round     │
                         │  Robin/GeoDNS)  │
                         └────────┬────────┘
                                  │
              ┌───────────────────┼───────────────────┐
              │                   │                   │
              ▼                   ▼                   ▼
       ┌─────────────┐     ┌─────────────┐     ┌─────────────┐
       │ Load        │     │ Load        │     │ Load        │
       │ Balancer 1  │     │ Balancer 2  │     │ Balancer 3  │
       │ (Active)    │     │ (Standby)   │     │ (Standby)   │
       └──────┬──────┘     └─────────────┘     └─────────────┘
              │                    │ (VRRP/Keepalived)
              │                    │
    ┌─────────┼─────────────────────┘
    │         │
    ▼         ▼
┌─────────┐ ┌─────────┐ ┌─────────┐
│ App     │ │ App     │ │ App     │
│ Server 1│ │ Server 2│ │ Server 3│
└────┬────┘ └────┬────┘ └────┬────┘
     │           │           │
     └───────────┼───────────┘
                 │
                 ▼
       ┌─────────────────┐
       │ Database        │
       │ (Primary)       │
       └────────┬────────┘
                │ Replication
                ▼
       ┌─────────────────┐
       │ Database        │
       │ (Replica)       │
       └─────────────────┘

This topology introduces:

• Virtual IP (VIP) failover using protocols like VRRP
• Health check probes at multiple levels (load balancer → app, app → database)
• Connection draining during deployments to gracefully handle in-flight requests
• Read replicas to distribute database read load

Despite the industry's enthusiasm for microservices, monolithic architecture offers compelling advantages that make it the optimal choice for many scenarios. Understanding these advantages is essential for making informed architectural decisions.

Development Simplicity:

Monoliths dramatically reduce the cognitive overhead of software development:

• Single Codebase: All code lives in one repository. Finding relevant code, understanding control flow, and tracing bugs doesn't require navigating multiple services.
• Unified Build Process: One build script, one artifact, one deployment pipeline. No coordination required between service deployments.
• Simple Debugging: Attach a debugger to one process and step through the entire request lifecycle. No distributed tracing infrastructure required.
• Refactoring Safety: IDE-supported refactoring (rename, extract, move) works across the entire codebase. Type checkers verify consistency at compile time.

Operational Simplicity:

Monoliths are significantly easier to operate than distributed systems:

• Deployment: Deploy one artifact to a known set of servers. Rollback by deploying the previous artifact.
• Monitoring: Aggregate logs from a known, fixed number of instances. Metrics collection is straightforward.
• Scaling: Scale by adding more identical instances behind the load balancer. No service discovery or orchestration required.
• Testing: Run integration tests against a single running instance. No need to mock external services or manage test environments for multiple services.

Cost Efficiency:

The total cost of ownership for monolithic applications is often substantially lower:

When Monolithic Architecture Excels:

1. Early-stage products: When requirements are unclear and rapid iteration is critical
2. Small to medium teams: When team size doesn't require independent deployment
3. Domain complexity over scale: When the challenge is business logic, not traffic volume
4. Regulated industries: When deployment auditing and approval processes are simpler with single artifacts
5. Latency-sensitive applications: When microsecond-level internal latency matters

While monolithic architecture offers significant advantages, it is not without challenges. Understanding these limitations helps engineers recognize when alternative architectures might be more appropriate and how to mitigate common problems within monolithic designs.

Scaling Constraints:

The most frequently cited limitation of monolithic architecture is scaling. Because the entire application is a single unit:

• Uniform Scaling: Every feature scales together. If the 'Reports' module needs 10x resources while 'Login' needs 1x, you still deploy 10x instances of everything.
• Resource Waste: Components with different resource profiles (CPU-bound versus memory-bound versus I/O-bound) can't be optimized independently.
• Database Ceiling: The shared database limits maximum throughput regardless of how many application instances you add.

Development Friction at Scale:

As monolithic applications grow, development velocity can suffer:

• Build Times: Large codebases take longer to compile, test, and package. A 30-minute build cycle severely impacts developer productivity.
• Merge Conflicts: Many developers working in the same codebase increases the likelihood of conflicting changes.
• Test Suite Duration: Comprehensive test suites for large monoliths can take hours, slowing the feedback loop.
• Blast Radius: A bug in any component can crash the entire application. There's no isolation between features.

Deployment Challenges:

Monolithic deployments can become increasingly risky as applications grow:

• All-or-Nothing Deployment: Every deployment touches the entire system. Even a CSS change requires redeploying the entire application.
• Extended Deployment Windows: Large applications take longer to deploy, extending maintenance windows and increasing rollback complexity.
• Coordination Overhead: When multiple teams contribute to a monolith, deployment schedules must be coordinated.
• Feature Flagging Complexity: Releasing features incrementally requires runtime feature flagging, adding code complexity.

Organizational Challenges:

Conway's Law states that organizations design systems mirroring their communication structures. Large monoliths can create organizational friction:

• Team Coupling: Teams can't work independently because their code is coupled.
• Responsibility Ambiguity: When everything is in one codebase, ownership of components becomes unclear.
• Knowledge Silos: Individuals become experts in specific parts, creating bus factor risks.
• Hiring Constraints: All developers must work with the monolith's technology stack.

The modular monolith represents an architectural pattern that captures the benefits of monolithic deployment while enforcing the clear boundaries typically associated with microservices. This approach recognizes that many monolithic problems stem not from the deployment model but from poor internal structure.

Core Principles:

A modular monolith maintains strict internal boundaries between logical modules while deploying as a single unit:

1. Module Independence: Each module has its own domain model, business logic, and data access layer.
2. Explicit Interfaces: Modules communicate only through well-defined APIs—no reaching into another module's internals.
3. Data Isolation: Each module owns its data and exposes it only through interfaces. Other modules cannot directly query another module's tables.
4. Enforced Boundaries: Build-time or runtime enforcement prevents violations of module boundaries.

┌─────────────────────────────────────────────────────────────┐
│                    Modular Monolith                          │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐       │
│  │   Orders     │  │  Inventory   │  │   Customers  │       │
│  │   Module     │  │   Module     │  │    Module    │       │
│  │              │  │              │  │              │       │
│  │ ┌──────────┐ │  │ ┌──────────┐ │  │ ┌──────────┐ │       │
│  │ │   API    │◄┼──┼►│   API    │◄┼──┼►│   API    │ │       │
│  │ └────┬─────┘ │  │ └────┬─────┘ │  │ └────┬─────┘ │       │
│  │      │       │  │      │       │  │      │       │       │
│  │ ┌────▼─────┐ │  │ ┌────▼─────┐ │  │ ┌────▼─────┐ │       │
│  │ │ Business │ │  │ │ Business │ │  │ │ Business │ │       │
│  │ │  Logic   │ │  │ │  Logic   │ │  │ │  Logic   │ │       │
│  │ └────┬─────┘ │  │ └────┬─────┘ │  │ └────┬─────┘ │       │
│  │      │       │  │      │       │  │      │       │       │
│  │ ┌────▼─────┐ │  │ ┌────▼─────┐ │  │ ┌────▼─────┐ │       │
│  │ │  Data    │ │  │ │  Data    │ │  │ │  Data    │ │       │
│  │ │  Access  │ │  │ │  Access  │ │  │ │  Access  │ │       │
│  │ └────┬─────┘ │  │ └────┬─────┘ │  │ └────┬─────┘ │       │
│  └──────┼───────┘  └──────┼───────┘  └──────┼───────┘       │
│         │                 │                 │               │
│         ▼                 ▼                 ▼               │
│  ┌─────────────────────────────────────────────────────┐   │
│  │              Shared Database (Logical Separation)    │   │
│  │   ┌─────────┐     ┌─────────┐     ┌─────────┐       │   │
│  │   │ orders_ │     │ inv_    │     │ cust_   │       │   │
│  │   │ tables  │     │ tables  │     │ tables  │       │   │
│  │   └─────────┘     └─────────┘     └─────────┘       │   │
│  └─────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────┘

Boundary Enforcement Strategies:

Maintaining module boundaries requires active enforcement:

Communication Patterns:

Modules in a modular monolith communicate through:

1. Synchronous Method Calls: Simple, direct, but creates dependencies
2. In-Process Events: Publish/subscribe within the process—loose coupling without network overhead
3. Shared Kernel: Common domain objects shared between modules (sparingly)

Migration Pathway:

The modular monolith serves as an excellent intermediate step toward microservices:

Monolith → Modular Monolith → Microservices
              ▲                    ▲
              │                    │
    Add internal boundaries    Extract modules
    without network overhead   to separate deployables

Modules with well-defined interfaces can be extracted to independent services when scaling requirements justify the operational overhead.

Understanding monolithic architecture benefits from examining real-world systems that have successfully employed this approach—some for decades of continuous operation.

Case Study: Stack Overflow

Stack Overflow, serving millions of developers daily, famously runs on a remarkably small monolithic infrastructure:

• Architecture: ASP.NET monolithic application
• Scale: Hundreds of millions of page views per month
• Infrastructure: Initially just 9 web servers, now optimized to handle traffic with minimal resources
• Database: SQL Server with carefully optimized queries and aggressive caching

Key Takeaways:

• Vertical optimization (better code, better queries, better caching) often outperforms horizontal scaling
• A well-optimized monolith can handle enormous traffic
• Performance engineering discipline matters more than architecture for many applications

Case Study: Ruby on Rails Applications

Many successful companies built their products as Rails monoliths:

• Shopify: Started as a monolith, evolved to a modular monolith, then selectively extracted services
• GitHub: Ran as a monolith for years before gradually extracting specific components
• Basecamp/Hey: Deliberately maintains a monolithic architecture as a strategic choice

Key Takeaways:

• Monoliths can scale to significant traffic levels
• Extraction to services should be driven by real constraints, not speculation
• Many "successful microservices" stories begin with successful monolith foundations

We've conducted a comprehensive examination of monolithic application architecture—the foundational pattern that remains relevant and often optimal for modern applications. Let's consolidate the essential concepts:

Transition to Microservices:

With a solid understanding of monolithic architecture established, we're now prepared to explore its distributed counterpart: microservices architecture. In the next page, we'll examine how breaking applications into independently deployable services creates new possibilities—and new challenges—for application layer networking.

The contrast between monolithic and microservices architecture will illuminate the fundamental trade-offs every architect must navigate: simplicity versus flexibility, efficiency versus scalability, and the critical role that network communication plays in shaping both approaches.