Monolith vs Modular Monolith vs Microservices: How to Choose

A startup with six engineers builds its first product as fourteen microservices, because "that is how big companies do it". Six months later, a one-line change to how usernames are displayed requires coordinated deployments of four services, local development needs twenty containers, every bug hunt crosses three repositories and five dashboards, and a single slow service regularly takes the product down. The team spends more time on plumbing than on features.

Meanwhile, a different company with three hundred engineers runs one enormous application that every team deploys together once a week; a bug in any team's code blocks everyone's release.

Both teams chose an architecture that did not fit their situation. This article compares the options honestly, explains how to draw boundaries if you do split, and covers the infrastructure that comes with services: API gateways, service discovery and service meshes.

• What monoliths, modular monoliths and microservices are.
• What microservices buy, and what they cost.
• Why a modular monolith is often the right first architecture.
• How to choose, based on team, domain and requirements.
• How to draw service boundaries and own data.
• Synchronous and asynchronous communication between services.
• API gateways, service discovery and service meshes.
• The distributed-monolith anti-pattern, and migrating with the strangler fig pattern.

One application, built and deployed as a single unit, usually with one database. All features live in one codebase and call each other with ordinary function calls.

Still one deployable unit, but internally divided into modules with strict boundaries: each module has a public interface, hides its internals, and owns its own tables (other modules do not read or write them directly). Modules call each other through their interfaces, in the same process.

The application is split into independently deployable services, each owning its data and running in its own processes, communicating over the network. Martin Fowler and James Lewis's article describes the style as building an application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, built around business capabilities and independently deployable (Microservices). Microsoft's architecture guidance describes the same characteristics and lists the challenges that come with them (Microservices architecture style).

MONOLITH                 MODULAR MONOLITH                 MICROSERVICES+-------------+          +---------------------+          [Accounts]--DB|  everything |          | Accounts | Photos   |          [Photos]----DB     network|  one DB     |          | Social   | Feed     |          [Social]----DB  <-- calls and+-------------+          | Notify   |          |          [Feed]------DB     events                         | each owns its tables |          [Notify]----DB                         +---------------------+                         one deployable, one database                         (separate schemas per module)

A widely cited observation, often called Conway's law, is that systems tend to mirror the communication structure of the organisations that build them. Microservices work best when service boundaries match team boundaries, so that most changes stay inside one team's services.

These costs are paid up front and continuously, while the benefits arrive only when the organisation and system are large enough to need them.

Martin Fowler's "Monolith First" essay observes that many successful microservice systems started as monoliths that were later split, and that starting with microservices risks drawing boundaries before the domain is understood (MonolithFirst). The essay also acknowledges counter-arguments; the point is not that microservices are wrong, but that service boundaries are expensive to move, and early in a product's life you do not yet know where they belong.

A modular monolith gives you most of the design discipline at a fraction of the cost:

• Clear boundaries and ownership inside one codebase.
• Module-owned data: each module has its own schema or tables; no cross-module joins in application code.
• In-process calls: fast, no network failures, real transactions across modules where genuinely needed.
• One deployment, one thing to monitor.
• Extraction later is mechanical: a module with a clean interface and its own tables can become a service when there is a reason.

A modular-monolith boundary in Java might look like this (an illustration):

// photos module: the only thing other modules may usepublic interface PhotoCatalog {    PhotoSummary find(long photoId);    List<PhotoSummary> recentByOwner(long ownerId, Cursor cursor, int limit);}// feed module depends on the interface, never on photos' tables or internal classesclass FeedBuilder {    private final PhotoCatalog photos;    FeedBuilder(PhotoCatalog photos) {        this.photos = photos;    }}

Build tools and architecture tests can enforce that modules only depend on each other's public interfaces.

A reasonable default: start with a modular monolith, keep asynchronous and resource-heavy work (media processing, notifications) in separate workers from day one, and extract services when a specific pressure (team independence, scaling, isolation) justifies the cost.

When you do split, boundaries matter more than anything else.

• Split by business capability, not technical layer. "Payments", "Catalogue", "Orders", "Notifications" are good services. "Database service", "Validation service" and "Frontend-facing service" are not: every feature would need to change all of them.
• Each service owns its data. The microservices.io description of the "Database per service" pattern explains why: a service's data is private and accessed only through its API, so services stay loosely coupled and can change their schemas independently (Database per service). Ownership can mean a separate database, or separate schemas with strict access rules.
• High cohesion, low coupling: things that change together belong together. If two services must always be deployed together, they are probably one service.
• Keep transactions inside a service. If an operation must be atomic, its data should live in one service (article 21).

Without shared tables, how do you answer "orders with customer names and product titles"?

• API composition: a service (or the gateway) calls the order, customer and product services and combines the results. Simple; adds latency and failure points.
• Replicated read models: a service subscribes to other services' events and keeps its own read-optimised copy (CQRS, article 27). Fast reads; eventually consistent.

A healthy pattern: synchronous calls for the few things a request truly needs, events for everything that can follow later. A request that fans out into a deep chain of synchronous calls is the classic way microservices become slow and fragile.

Clients should not need to know about dozens of services. An API gateway is a reverse proxy (article 08) that serves as the single entry point for clients and routes each request to the right service. Microsoft's Gateway Routing pattern describes routing requests to multiple services through a single endpoint, so clients are decoupled from how services are split and deployed (Gateway Routing pattern).

Typical gateway responsibilities:

• Routing by path or host (/v1/photos/* to the photos service).
• TLS termination and edge security.
• Authentication (validate tokens once at the edge) and coarse authorisation.
• Rate limiting and quotas per client (article 31).
• Request and response shaping, API versioning, CORS.
• Aggregation for specific clients: a backend for frontend (BFF) gateway that combines several service calls into one response tailored to the mobile app, reducing round trips (article 03).
• Observability: access logs, metrics and the start of traces.

What should not live in the gateway: business logic. A gateway that accumulates domain rules becomes a new monolith that every team must change. It must also be highly available and fast, because every request passes through it.

Service instances come and go (autoscaling, deployments, failures), so their addresses change constantly. Service discovery lets a caller find healthy instances of a service by name.

• Server-side discovery: the caller sends requests to a stable name or address (a load balancer or virtual IP), which forwards to a healthy instance. Kubernetes Services work this way: a Service gives a set of pods a stable name and virtual address and routes traffic to them, while pods come and go (Kubernetes: Service).
• Client-side discovery: the caller looks up healthy instances in a service registry and load-balances itself. Registries are often built on consistent stores such as etcd or ZooKeeper (article 22), or tools such as Consul.

Either way, instances register (or are registered by the platform), health checks remove broken ones, and callers cache lookups briefly.

As service counts grow, every service needs the same networking features: mTLS between services, retries, timeouts, circuit breaking, load balancing and telemetry. A service mesh moves these into a proxy deployed next to each service instance (a sidecar), configured centrally. Envoy is a widely used proxy for this role; its documentation describes it as an L7 proxy and communication bus designed for large service-oriented architectures (What is Envoy).

Benefits: consistent policies without changing application code. Costs: another complex system to operate, extra latency per hop, and debugging that spans application and mesh. It is worth it at significant scale; it is rarely the first thing a small team should add.

The worst outcome is a system split into services that still behave like one application:

• services share a database and read each other's tables;
• a change requires deploying several services together in a fixed order;
• a request passes through long synchronous chains, so one slow service stalls everything;
• services share large common libraries containing domain models, forcing lockstep upgrades.

This distributed monolith has all the costs of microservices (network failures, operational load) and none of the benefits (independent deployment, isolation). If you see these symptoms, either merge the tightly coupled services or fix the boundaries and data ownership.

Rewriting a large monolith from scratch is risky. The strangler fig approach, named by Martin Fowler after vines that gradually grow around a tree, replaces a system incrementally: put a facade (often the API gateway) in front of the old system, build new functionality or extract one capability at a time as a new service, route that capability's traffic to it, and repeat until the old system can be retired (StranglerFigApplication).

Step 1: Clients -> Gateway -> Monolith (everything)Step 2: Clients -> Gateway -> /notifications/* -> Notification service                           -> everything else  -> MonolithStep 3: Clients -> Gateway -> several extracted services, smaller monolith ...

Extract first what has the clearest boundary and the strongest reason (different scaling, different release cadence, isolation), and migrate its data ownership too, not only its code.

Today (one team of eight engineers): a modular monolith API (modules: accounts, photos, social graph, feed, likes), stateless and horizontally scaled behind a load balancer, plus separate worker deployments for thumbnails, moderation and notifications consuming from queues. One PostgreSQL cluster with a schema per module. This is not "naive"; it is the right shape for this team.

Pressure arrives (three teams, feed load growing fast):

Clients -> API gateway (auth, rate limits, routing, mobile BFF)             |-- /v1/feed/*  ----------> Feed service ------> feed stores             |-- /v1/notifications/* --> Notification service             `-- everything else ------> Core (modular monolith) --> PostgreSQLCore --outbox--> event broker --> Feed service, Notification service, search indexer

The design records why each split happened, and leaves the rest together until a similar reason appears.

• Choosing microservices for a small team or an unclear domain.
• Splitting by technical layer instead of business capability.
• Sharing a database between services.
• Replacing in-process calls with long synchronous network chains.
• Putting business logic into the gateway.
• Big-bang rewrites instead of incremental extraction.

• Do not start with "microservices". Start with requirements and team context, then justify the style.
• If you propose services, name each with its business capability and the data it owns.
• Say which interactions are synchronous and which are events.
• Mention an API gateway at the edge and how services find each other.
• If asked "monolith or microservices?", answer "a modular monolith first, extracting X and Y because...", with the reasons.

• Next: Event-Driven Architecture, CQRS and Event Sourcing, the asynchronous half of service communication.
• Later: Security in System Design covers authentication at the gateway and between services.