Software Architecture & Design

The Monolith

A monolith deploys the entire application as a single unit. All modules share the same process, memory, and database. Despite its reputation, a well-structured monolith is often the right starting point.

Strengths

Simple to develop, test, and deploy. A single codebase means easy debugging and straightforward local development. Database transactions are trivial since everything shares one database -- no distributed consistency headaches.

Weaknesses

As the codebase grows, tight coupling between modules makes changes risky. Scaling is all-or-nothing: you scale the entire application even if only one module is under load. Deployment of a one-line fix requires redeploying everything. Team autonomy suffers as everyone works in the same codebase.

Modular Monolith

The best of both worlds. The application is a single deployable unit, but internally it is organized into well-defined modules with explicit boundaries and APIs. Each module owns its data and communicates with others through defined interfaces. This gives you the simplicity of a monolith with the structural discipline that makes a future migration to microservices feasible.

Microservices Architecture

Each service owns its own database, deployment pipeline, and is typically maintained by a small, autonomous team. Services communicate over the network, introducing new trade-offs around consistency, latency, and operational complexity.

Communication Styles

Saga Pattern for Distributed Consistency

Without a shared database, you cannot use ACID transactions across services. The saga pattern coordinates a sequence of local transactions, where each service performs its step and publishes an event. If any step fails, compensating transactions undo the previous steps.

Event-Driven Architecture

Systems communicate by producing and consuming events rather than making direct calls. An event represents a fact -- something that happened -- and is immutable once published.

Types of Events

Benefits

Loose coupling between producer and consumer -- the producer does not know or care who consumes the event. Natural audit trail since events are an immutable log of what happened. Enables temporal decoupling: services can process events at their own pace. Scales well because consumers can be added without modifying the producer.

Challenges

Eventual consistency is the default -- the system may be temporarily inconsistent. Debugging is harder because there is no single request path to trace. Event ordering, idempotency, and exactly-once processing are non-trivial. Schema evolution of events requires careful versioning.

Hexagonal Architecture & Domain-Driven Design

Hexagonal (Ports & Adapters)

The core idea: your business logic sits at the center and knows nothing about the outside world. It defines ports (interfaces) for what it needs. Adapters implement those ports to connect to databases, APIs, message brokers, or UIs. Dependencies always point inward.

Bounded Contexts

A bounded context is a boundary within which a particular domain model applies. The same word (e.g., "Account") can mean different things in different contexts (banking vs. user management). Each context has its own ubiquitous language -- the shared vocabulary between developers and domain experts within that boundary.

DDD Building Blocks

SOLID Principles

Five principles for writing maintainable, flexible object-oriented code. They reduce coupling, increase cohesion, and make code easier to change.

// Dependency Inversion in practice
// High-level module depends on abstraction, not concrete DB
interface OrderRepository {
  save(order: Order): void;
  findById(id: string): Order;
}

class OrderService {
  constructor(private repo: OrderRepository) {} // depends on interface
  placeOrder(order: Order) {
    // business logic...
    this.repo.save(order); // doesn't know if it's Postgres, Mongo, or in-memory
  }
}

// Low-level module implements the abstraction
class PostgresOrderRepository implements OrderRepository {
  save(order: Order) { /* SQL insert */ }
  findById(id: string) { /* SQL select */ }
}

Design Patterns That Matter

Not all 23 GoF patterns are equally useful. Here are the ones you will actually reach for in modern backend and distributed systems.

Creational

Behavioral

Structural

Distributed System Patterns