When designing a system, one of the first decisions you’ll face is how to structure your application. Three architectural patterns dominate modern software development, each with distinct trade-offs.

A monolith packages everything into a single deployable unit. Your UI, business logic, and data access all run in the same process, communicating through function calls rather than network requests.

This works brilliantly for early-stage products, small teams, and tightly coupled domains. You can move fast, validate ideas quickly, and avoid the operational overhead of managing multiple services. The trade-off is that scaling means replicating everything, deployments become riskier as the codebase grows, and a bug anywhere can bring down the whole system.

Many successful systems start here and extract services later once domain boundaries become clearer. A modular monolith with well-structured internal boundaries makes this transition much easier.

Distributed systems split your application into multiple independent services communicating over the network. This includes both service-oriented architecture and its modern evolution, microservices.

Each service owns a specific capability, can have its own database, and can be developed, deployed, and scaled independently. This suits large organisations with multiple teams, systems with components that have very different scaling requirements, and mature products with well-understood boundaries.

The challenges are significant though. Network communication introduces latency and partial failures. Distributed transactions require patterns like sagas or eventual consistency. Operational overhead increases dramatically, and debugging issues that span services requires sophisticated tooling.

Serverless abstracts away infrastructure entirely. You deploy individual functions that run on-demand, with your cloud provider handling scaling, availability, and capacity planning.

This is great for unpredictable or spiky workloads, event-driven workflows like file processing or webhooks, and MVPs where speed matters more than optimisation. You pay per execution, meaning near-zero cost when idle.

The constraints include cold start latency, execution time limits (typically 15 minutes maximum), and potential vendor lock-in. Debugging and local development can also be more difficult.

A note on categorisation: Serverless is technically a form of distributed architecture, but the operational model is different enough that it’s useful to consider separately. You don’t manage the distribution - the platform does.

There’s no universally correct answer. Small teams often thrive with monoliths due to reduced operational complexity. Large organisations with multiple teams benefit from distributed architectures that enable independent work. Serverless suits unpredictable workloads and teams wanting to minimise operational overhead.

Consider your team size, acceptable operational complexity, scaling requirements, and how quickly you need to reach production. The right architecture is the one that matches your current constraints while leaving room to evolve.

You may also like these:

Free subscribers also get a little bonus:

🎁 The System Design Interview Preparation Cheat Sheet

If you’re into visuals, paid subscribers unlock:

→ My Excalidraw system design template – so you have somewhere to start → My Excalidraw component library – used in the diagram of this issue

No pressure though. Your support helps me keep writing, and I appreciate it more than you know ❤️

No posts