Almost every engineering team eventually asks the same question: should we break our one big application into a “small city” of services, or is it wiser to keep living in the house we already have?

Imagine you are building a house. In the beginning, you build one building: a kitchen, a bedroom, a living room, all under one roof, sharing one front door, one electricity meter, and one water pipe. This is simple. You know exactly where everything is, and if something breaks, you go to that one house and fix it.

Now imagine a small city. Instead of one house, there are separate buildings: a bakery, a school, a hospital, a post office. Each building has its own staff, its own door, its own rules. If the bakery catches fire, the hospital keeps running. But now you need roads to connect the buildings, traffic rules, postal services between them, and a lot more coordination.

This is, at its heart, the difference between a monolith (the one big house) and microservices (the small city of separate buildings). This tutorial is about the very practical, very common real‑world question that every engineering team eventually asks: “Should we break our one big house into a small city, or should we keep living in the house we already have?”

A short history of how we got here

In the 1990s and early 2000s, almost every application was built as a single, large program. This was not a “choice” in the modern sense — it was simply how software was built. You wrote your code, packaged it into one deployable unit (a WAR file, an EXE, a single running process), and deployed it on one or a handful of servers. This approach later got the name monolith (from Greek: “mono” = one, “lithos” = stone — one single block of stone).

As companies like Amazon, Netflix, and eBay grew from thousands to hundreds of millions of users, their single big applications started to strain. Small teams had to coordinate deployments with hundreds of other engineers. A tiny bug in the “recommendation” part of the code could crash the entire “checkout” part, because everything lived in the same process. Around 2011–2014, the term microservices became popular to describe an alternative style: many small, independently deployable services, each owning a narrow piece of business functionality, communicating over the network.

For most of the last decade, “microservices” was treated in the industry almost like a fashion trend — the assumption was “bigger companies use microservices, so we should too.” But since around 2018–2020, and especially by the mid‑2020s, there has been a strong, well‑documented, industry‑wide correction. Many companies — including some very famous ones — have publicly gone back from microservices to monoliths, or adopted a middle‑ground design. This tutorial explains exactly why, and gives you a clear, defensible framework for making this decision yourself.

This tutorial will not tell you that monoliths are always good or that microservices are always bad. Instead, it will teach you how to think like a senior architect: how to read the signals in your own team, product, and traffic, and make the right call — including the increasingly common and often correct call to stay with a monolith.

Architecture decisions are some of the most expensive decisions a team can make. Choosing the wrong one does not fail loudly on day one — it fails slowly, over months and years, through frustrated engineers, ballooning cloud bills, and slower feature delivery.

The core motivation for microservices

Microservices were invented to solve real, painful problems that show up at a certain scale:

• Team scaling: when 200 engineers work on one codebase, they constantly step on each other’s changes.
• Independent deployment: a team wants to release its own feature without waiting for 50 other teams to finish testing theirs.
• Independent scaling: one part of the system (say, video encoding) needs 1,000 servers, while another part (say, user settings) needs only 2. In a monolith, you must scale the whole thing together.
• Technology diversity: one team wants to use Python for machine learning; another wants Java for transaction processing.
• Fault isolation: if one small service crashes, the rest of the system should keep working.

The problem this tutorial addresses

The real‑world problem is this: teams often adopt microservices before they actually have these problems. A five‑person startup with 200 users does not have a “200 engineers stepping on each other” problem. A product with predictable, low traffic does not have an “independent scaling” problem. Yet these teams still split into 30 microservices — because it is trendy, because a conference talk made it sound exciting, or because an engineer wants it on their résumé.

The result is what senior engineers now half‑jokingly call a “distributed monolith” — all the operational pain of microservices (network calls, deployment pipelines, service discovery, distributed debugging) with none of the benefits (because the services are still so tightly coupled that you cannot actually deploy or scale them independently).

Why “staying with a monolith” is a legitimate engineering decision

This tutorial’s central motivation is to correct an industry bias. For years, choosing a monolith was seen as “not scaling,” “old‑fashioned,” or “not serious engineering.” In reality, staying with a monolith is very often the more sophisticated, more disciplined decision, because it requires you to resist hype and instead measure your actual problems.

By the end of this tutorial, you will be able to look at a real team, a real product, and real traffic numbers, and confidently say: “Based on these specific signals, we should stay with our monolith” — or “based on these other specific signals, we are ready to split out services” — and explain exactly why, in a way that would satisfy a room full of senior engineers or a technical interviewer.

Before comparing architectures, it helps to lock down a small, precise vocabulary you will meet again in interviews, code reviews, and production war stories.

3.1 What is a Monolith?

What it is: a monolithic architecture is an application built and deployed as a single, unified unit. All the code — user interface, business logic, and data access — lives in one codebase and runs as one process (or a small number of identical copies of that same process).
Why it exists: it is the natural, simplest way to build software. You do not need to invent network boundaries between parts of your own program that do not need them.
Where it is used: most startups, most internal business tools, most small‑to‑medium products, and — importantly — many very large, very successful products (Shopify, Stack Overflow, and Basecamp are famous examples) run as monoliths, sometimes handling billions of requests.

3.2 What are Microservices?

What it is: microservices architecture splits an application into many small, independent services. Each service owns one specific business capability (for example, “Payments,” “Inventory,” “Shipping”), has its own codebase, its own database (usually), and communicates with other services over the network — typically through HTTP/REST APIs or asynchronous messaging.
Why it exists: to let large organisations split work across many independent teams, deploy pieces of the system separately, and scale only the parts that need it.
Where it is used: large‑scale platforms with many independent teams and highly variable load across different parts of the system — Netflix, Amazon, Uber, and other Uber‑scale ride‑sharing and streaming platforms are classic examples.

3.3 The Modular Monolith (the important middle ground)

What it is: a modular monolith is a single deployed application (like a monolith), but internally organised into clean, well‑separated modules with clear boundaries and defined interfaces between them — as if each module were “pre‑packaged” to become its own microservice one day, without actually paying the network cost today.
Why it exists: to get the simplicity of one deployment while still avoiding the “big ball of mud” problem where every part of the code touches every other part with no boundaries.
Where it is used: this is the design most senior architects recommend today as the default starting point, and increasingly, as a permanent architecture, for the majority of products.

3.4 Key Vocabulary You Need

3.5 The One‑Sentence Answer to the Tutorial’s Question

The rest of this tutorial teaches you how to recognise each of those signals concretely.

A well‑built monolith is not “one file with 50,000 lines of spaghetti code.” It is a disciplined, layered structure — and it looks very different from a healthy microservices system on the moving‑parts level.

4.1 The anatomy of a monolith

A good monolith has clean internal layers, usually organised like this:

4.2 The anatomy of microservices

4.3 Comparing the moving parts

Trace a single request through both worlds. The same “Buy Now” button turns into a very different journey depending on whether you are inside a monolith or a network of services.

5.1 How a request flows through a monolith

Let’s trace a real example: a user clicks “Buy Now” on a bookstore website built as a monolith.

1. 1. Browser sends an HTTP request to the server.

   Standard start of any web transaction.

2. 2. A single running process receives the request at a controller (e.g., OrderController).

   Everything else will happen inside this same process.

3. 3. The controller calls the OrderService.

   This is a plain in‑memory function call, taking microseconds, not a network call.

4. 4. OrderService calls InventoryService and PaymentService.

   Again, plain function calls within the same process.

5. 5. All three services use the same shared database connection pool.

   Reads and writes happen inside a single database transaction, so either everything succeeds together or everything rolls back together.

6. 6. The controller returns an HTTP response.

   One thread, one continuous stack, one clear story.

Notice: steps 3, 4, and 5 never leave the process. There is no network involved. This is why monoliths are inherently simpler to reason about — a bug or slowdown in one part is visible in the same stack trace, the same logs, the same debugger session.

5.2 A minimal Java monolith example

Below is a simplified but realistic slice of a Java monolith. Notice that OrderService simply calls other services directly as Java objects — no network layer involved.

// A single Spring Boot application - ALL of this runs in one process
@Service
public class OrderService {

    private final InventoryService inventoryService;
    private final PaymentService paymentService;
    private final NotificationService notificationService;

    public OrderService(InventoryService inventoryService,
                         PaymentService paymentService,
                         NotificationService notificationService) {
        this.inventoryService = inventoryService;
        this.paymentService = paymentService;
        this.notificationService = notificationService;
    }

    @Transactional // one database transaction covers the whole operation
    public OrderResult placeOrder(OrderRequest request) {
        // Direct, in-memory method calls - no network, no timeouts, no retries
        boolean reserved = inventoryService.reserveStock(request.getItemId(), request.getQty());
        if (!reserved) {
            return OrderResult.failed("Out of stock");
        }

        boolean charged = paymentService.charge(request.getCustomerId(), request.getAmount());
        if (!charged) {
            inventoryService.releaseStock(request.getItemId(), request.getQty());
            return OrderResult.failed("Payment declined");
        }

        notificationService.sendOrderConfirmation(request.getCustomerId());
        return OrderResult.success();
    }
}

Because InventoryService, PaymentService, and NotificationService are just Java classes in the same process, the @Transactional annotation can wrap all their database work into one atomic transaction. If anything fails, the database automatically rolls everything back. This kind of guarantee is easy in a monolith and genuinely hard in microservices.

5.3 The same flow in microservices (for comparison)

// Order Service - now a SEPARATE deployed application
@Service
public class OrderService {

    private final RestTemplate restTemplate; // network client

    public OrderResult placeOrder(OrderRequest request) {
        // This is now a real HTTP call over the network - can time out, fail, retry
        ResponseEntity<Boolean> reserved = restTemplate.postForEntity(
            "http://inventory-service/api/reserve", request, Boolean.class);

        if (!Boolean.TRUE.equals(reserved.getBody())) {
            return OrderResult.failed("Out of stock");
        }

        ResponseEntity<Boolean> charged = restTemplate.postForEntity(
            "http://payment-service/api/charge", request, Boolean.class);

        if (!Boolean.TRUE.equals(charged.getBody())) {
            // Must manually call another network endpoint to undo the reservation
            restTemplate.postForEntity("http://inventory-service/api/release", request, Void.class);
            return OrderResult.failed("Payment declined");
        }

        // Fire-and-forget event, usually via a message broker like Kafka
        // eventPublisher.publish(new OrderPlacedEvent(request));
        return OrderResult.success();
    }
}

Every arrow is now a real network call. If payment-service is slow or down, order-service must handle timeouts, retries, and partial failures. There is no automatic database transaction spanning both services — this is why microservices architectures need patterns like the Saga pattern (explained in Chapter 15) to keep data consistent, which is significantly more complex than a single @Transactional annotation.

One process, one transaction — or five actors and three network hops. The lifecycle of a request looks very different depending on which world you are in.

6.1 Request lifecycle in a monolith

6.2 Request lifecycle in microservices

6.3 The application lifecycle (deployment over time)

In a monolith, the lifecycle of a change is: write code → run tests → build one artifact → deploy one artifact → done. In microservices, the lifecycle multiplies: each of the (say) 15 services has its own version, its own pipeline, its own rollout schedule, and teams must track “which version of Service A is compatible with which version of Service B” — a real and often underestimated coordination cost.

Neither architecture is universally “better.” Each earns its keep in specific situations, and each has genuine, well‑known costs. Here they are, plainly.

7.1 Advantages of staying with a monolith

7.2 Advantages and disadvantages of microservices (for context)

7.3 The trade‑off summary table

A monolith is not slow just because it is a monolith. Almost every performance ceiling that people blame on “the monolith” turns out to be a database, caching, or algorithmic issue that would exist in microservices too.

8.1 Vertical vs. horizontal scaling

Vertical scaling means giving your one server more CPU and RAM (a bigger machine). Horizontal scaling means running more copies of your application across more machines. A key myth to bust: monoliths can absolutely scale horizontally. You simply run 10 identical copies of the same monolith behind a load balancer.

What a monolith cannot do is scale each internal module independently. If “search” needs 50 instances but “user profile” needs 2, a monolith forces you to run 50 full copies of everything, wasting resources on the parts that did not need scaling. This is the single strongest, most legitimate technical argument for microservices — but it only matters once your traffic is large enough and lopsided enough for the wasted resources to actually cost more than the operational overhead of splitting.

8.2 When uneven load does not justify splitting

8.3 Caching in a monolith

A monolith can still get excellent performance through caching layers — for example, an in‑memory cache (like Caffeine in Java) for frequently‑read, rarely‑changed data, and a shared cache (like Redis) for data that must be consistent across multiple instances.

@Service
public class ProductCatalogService {

    private final Cache<String, Product> localCache = Caffeine.newBuilder()
            .maximumSize(10_000)
            .expireAfterWrite(Duration.ofMinutes(5))
            .build();

    public Product getProduct(String productId) {
        return localCache.get(productId, id -> loadProductFromDatabase(id));
    }
}

This is a simple in‑process cache. It requires zero extra infrastructure — no separate cache cluster to run and monitor — because everything lives inside the same monolith process. This is a good example of a “microservices‑style” performance technique that a monolith can adopt for free.

8.4 Algorithmic and concurrency considerations

Performance inside a monolith often comes down to classic computer‑science fundamentals rather than architecture style:

• Concurrency: Java’s thread pools (ExecutorService), or newer lightweight virtual threads (Project Loom, standard since Java 21), let a single monolith process handle tens of thousands of concurrent requests efficiently.
• Connection pooling: a well‑tuned database connection pool (e.g., HikariCP) lets one monolith serve very high query volumes.
• Indexing and query optimisation: a single well‑indexed database, with good understanding of Big‑O complexity for queries, often outperforms a distributed system where the same query now requires joining data across network calls (a “distributed join”).

High availability is not a microservices feature. It is a property you earn by running multiple copies across failure domains — and a monolith can do that just as well as a service‑based system.

9.1 Redundancy without microservices

High availability means the system keeps working even when parts of it fail. A monolith achieves this the same way most systems do: by running multiple identical copies across different servers, data centres, or cloud “availability zones,” so if one fails, others take over.

9.2 The CAP theorem and why it matters less here

The CAP theorem states that during a network partition (a communication failure between nodes), a distributed system must choose between Consistency (everyone sees the same data) and Availability (the system keeps responding). A monolith with one database mostly sidesteps this dilemma for its own internal logic, because there is no network partition possible between “modules” that live in the same process — the only place CAP applies is between the monolith and its database replicas, which is a much smaller, well‑understood problem that database vendors have already solved with mature replication technology.

9.3 Failure recovery patterns in a monolith

• Health checks + auto‑restart: if an instance crashes, the orchestrator (e.g., Kubernetes) restarts it automatically.
• Database failover: if the primary database fails, a replica is promoted automatically.
• Graceful degradation: a monolith can catch exceptions from a non‑critical module (e.g., “recommendations”) so that a failure there does not take down “checkout,” even within the same process — using techniques like bulkheading and try/catch isolation, similar in spirit to microservice fault isolation but without the network.

public OrderResult placeOrder(OrderRequest request) {
    OrderResult result = coreOrderService.placeOrder(request);

    // Non-critical module: isolate its failure so it never breaks the order flow
    try {
        recommendationService.recordPurchaseForRecommendations(request);
    } catch (Exception e) {
        log.warn("Recommendation tracking failed, continuing anyway", e);
    }

    return result;
}

Even inside one process, you can design “soft” boundaries so a non‑critical feature’s failure does not cascade. This gives you a meaningful slice of microservices’ fault‑isolation benefit, without any network calls.

Every network endpoint is a potential entry point for an attacker. A monolith typically exposes far fewer network endpoints than a microservices system, which materially shrinks the attack surface.

10.1 A smaller attack surface

In a monolith, internal module‑to‑module communication never leaves the process and therefore is never exposed to the network at all.

10.2 Practical security practices for a monolith

• Input validation at the controller layer to block injection attacks (SQL injection, XSS).
• Parameterised queries / ORM usage (e.g., JPA/Hibernate) instead of building raw SQL strings.
• Role‑based access control (RBAC) enforced centrally, since there is only one place to enforce it.
• Encryption in transit (TLS) between the client and the monolith, and encryption at rest for the database.
• Centralised audit logging — since everything runs in one process, you get one unified audit trail “for free,” instead of stitching audit logs from many services.

@RestController
@RequestMapping("/api/orders")
public class OrderController {

    @PreAuthorize("hasRole('CUSTOMER')") // enforced in one central place
    @PostMapping
    public ResponseEntity<OrderResult> placeOrder(@Valid @RequestBody OrderRequest request) {
        // @Valid triggers input validation before any business logic runs
        return ResponseEntity.ok(orderService.placeOrder(request));
    }
}

@Valid and @PreAuthorize are Spring Security/Validation annotations. Because the whole request pipeline lives in one process, security rules are easy to apply consistently everywhere, with far less risk of one forgotten, unsecured internal endpoint (a very common real‑world microservices vulnerability).

Observability is the ability to understand what is happening inside your system from the outside — through logs, metrics, and traces. It is dramatically simpler in a monolith.

11.1 Why observability is simpler in a monolith

In a monolith, one request generates one continuous stack trace and one continuous log stream. In microservices, the same request is scattered across multiple services’ logs, requiring a distributed tracing system (like Jaeger or Zipkin) just to reconstruct what happened.

11.2 Practical monitoring setup for a monolith

• Application metrics: response times, error rates, request counts — easily exposed via a library like Micrometer and visualised in Grafana.
• Health endpoints: a single /actuator/health endpoint (Spring Boot) tells you the state of the entire application.
• Structured logging: logging in JSON format so logs can be indexed and searched (e.g., with the ELK stack: Elasticsearch, Logstash, Kibana).
• Alerting: a small number of alerts (CPU, memory, error rate, response time) cover the whole system, instead of needing separate alert rules per microservice.

// Exposing a simple custom metric with Micrometer in a Spring Boot monolith
@Service
public class OrderService {
    private final Counter ordersPlacedCounter;

    public OrderService(MeterRegistry registry) {
        this.ordersPlacedCounter = Counter.builder("orders.placed.total")
                .description("Total number of orders placed")
                .register(registry);
    }

    public OrderResult placeOrder(OrderRequest request) {
        OrderResult result = /* ... business logic ... */ null;
        ordersPlacedCounter.increment();
        return result;
    }
}

This one counter, exposed automatically to a monitoring system like Prometheus, gives visibility into the whole “orders placed” business metric — no need to aggregate this number across multiple separately‑deployed services.

A monolith on modern cloud infrastructure gets almost all the deployment sophistication people associate with microservices — rolling updates, health checks, container orchestration — without needing to run dozens of separate service pipelines.

12.1 The deployment pipeline of a monolith

12.2 Cloud deployment options for monoliths

• Platform‑as‑a‑Service (PaaS) like Heroku, Render, or AWS Elastic Beanstalk — you upload your app, and the platform handles servers, load balancing, and scaling.
• Containerised deployment — package the monolith into a single Docker image and run multiple replicas using Kubernetes, ECS, or a simple container orchestrator, getting the modern deployment benefits (rolling updates, auto‑restart) without the complexity of managing dozens of services.
• Serverless‑adjacent hosting — some cloud providers let you run a “monolith” behind an auto‑scaling group where the number of instances grows and shrinks with load automatically.

FROM eclipse-temurin:21-jre
COPY target/bookstore-app.jar /app/app.jar
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "/app/app.jar"]

One image, one ENTRYPOINT. Compare this to a microservices system, where you would maintain a separate Dockerfile, a separate image registry entry, and a separate deployment manifest for every one of your services.

12.3 Rolling updates and zero‑downtime deploys

Modern deployment tools (like Kubernetes) support rolling updates: new instances of the monolith are started, health‑checked, and only then are old instances shut down — giving zero‑downtime deployments even for a “big” application, without needing per‑service release trains.

A shared relational database is not a weakness of a monolith. It is one of its most powerful assets — and it is what unlocks ACID transactions, cheap joins, and referential integrity that microservices spend enormous effort trying to reinvent.

13.1 The shared database model

Monoliths typically use one shared relational database (like PostgreSQL or MySQL). This gives you:

• ACID transactions (Atomicity, Consistency, Isolation, Durability) across all your business logic, guaranteeing that related writes either all succeed or all fail together.
• Simple JOIN queries across related data (e.g., joining “orders” with “customers” with “products”) in a single, fast SQL query — instead of making three network calls and joining data manually in application code (a “distributed join,” which is slower and more error‑prone).
• Referential integrity enforced by the database itself (foreign keys), preventing orphaned or inconsistent data.

13.2 Scaling the database without splitting services

• Read replicas: copies of the database that handle read‑heavy traffic, while the primary handles writes.
• Vertical scaling: bigger database instances (more CPU/RAM) as load grows.
• Table partitioning: splitting one huge table (e.g., “orders” with 500 million rows) into smaller partitions by date or region, invisible to the application code.
• Caching layers: Redis or Memcached in front of the database for hot, frequently‑read data.

13.3 Load balancing a monolith

A load balancer is a component that distributes incoming requests across multiple servers, so no single server is overwhelmed. Common algorithms include:

• Round robin: requests are sent to each server in turn.
• Least connections: requests go to whichever server currently has the fewest active connections.
• Consistent hashing: useful when you want the same user routed to the same server repeatedly (session stickiness).

A monolith still has APIs — it just does not have the network cost between its own modules. Comparing the two side by side makes the trade very concrete.

14.1 How a monolith exposes APIs

Even a monolith exposes external APIs to mobile apps, web front‑ends, or partner integrations — the difference is that internally, those API handlers call regular functions, not other network services.

@RestController
@RequestMapping("/api/v1/orders")
public class OrderController {

    private final OrderService orderService; // in-process dependency

    @PostMapping
    public ResponseEntity<OrderResult> create(@RequestBody OrderRequest request) {
        return ResponseEntity.ok(orderService.placeOrder(request));
    }

    @GetMapping("/{orderId}")
    public ResponseEntity<Order> get(@PathVariable String orderId) {
        return ResponseEntity.ok(orderService.findById(orderId));
    }
}

14.2 API communication styles in microservices

• Synchronous REST/HTTP: Service A calls Service B and waits for a response — simple but creates tight runtime coupling and cascading latency.
• gRPC: a faster, binary, strongly‑typed alternative to REST, popular for internal service‑to‑service calls.
• Asynchronous messaging (Kafka, RabbitMQ): Service A publishes an event; other services react independently, without waiting — more resilient, but harder to reason about and debug.

14.3 The API Gateway pattern

In microservices, an API Gateway is a single entry point that routes external requests to the correct internal service, and often handles authentication, rate limiting, and request logging centrally. Interestingly, a monolith gets a “free” API gateway — the monolith’s own controller layer already does all of this routing internally, with no extra component required.

14.4 Side‑by‑side: adding a new feature

The interesting patterns are not “monolith vs. microservices.” They are the shapes that make either architecture work — and the anti‑patterns that quietly ruin both.

15.1 Good patterns for a monolith

Modular Monolith / Package‑by‑Feature

Organise code by business capability (e.g., com.bookstore.orders, com.bookstore.inventory, com.bookstore.payments) instead of by technical layer (controllers, services, repositories all mixed together). Each package exposes a small, clear public interface, and internal details stay package‑private.

com.bookstore.orders
  |-- OrderController.java       (public API)
  |-- OrderService.java          (public API)
  |-- OrderRepository.java       (package-private)
  '-- OrderEntity.java           (package-private)

com.bookstore.inventory
  |-- InventoryController.java
  |-- InventoryService.java      (public API used by orders module)
  |-- InventoryRepository.java   (package-private)
  '-- InventoryEntity.java       (package-private)

The orders module can call InventoryService (a public class), but cannot directly touch InventoryRepository or InventoryEntity — this keeps a clean boundary, exactly like a microservice boundary, but enforced by the compiler instead of the network.

Strangler Fig Pattern

Named after a vine that slowly grows around a tree and eventually replaces it, this pattern lets you gradually extract functionality out of a monolith into a new service over time, routing a small slice of traffic to the new service while the monolith still handles the rest — instead of a risky “big bang” rewrite.

Saga Pattern (for when you do split)

Since microservices cannot use one shared database transaction, the Saga pattern coordinates a sequence of local transactions across services, with defined “compensating actions” to undo previous steps if a later step fails.

15.2 Anti‑patterns to avoid

The Distributed Monolith (the most dangerous anti‑pattern)

This happens when a team splits into microservices, but the services are so tightly coupled (shared database, synchronous call chains, shared deployment schedule) that they must all be deployed together anyway — giving you all of microservices’ network overhead and complexity, with none of its independence benefits.

Premature Decomposition

Splitting services based on guesses about future scaling needs, before the team has any real evidence (traffic data, team friction, deployment conflicts) that those specific boundaries are correct. This almost always leads to services being split along the wrong lines, requiring painful re‑splitting later.

The Big Ball of Mud (the monolith anti‑pattern)

This is the failure mode on the other side: a monolith with no internal structure at all, where every class can call every other class with no boundaries. This is the actual thing people are afraid of when they say “monoliths do not scale” — but the fix for a Big Ball of Mud is a Modular Monolith, not necessarily microservices.

Discipline beats architecture style. A modular, well‑monitored, feature‑flagged monolith outperforms a chaotic microservices sprawl almost every time.

16.1 Best practices when staying with a monolith

• Organise code by business feature/module, not by technical layer alone.
• Enforce module boundaries with package‑private visibility, build‑tool module systems (e.g., Java Platform Module System), or architectural tests (e.g., ArchUnit) that fail the build if boundaries are violated.
• Keep the database schema clean, with clear ownership of tables by module, even if they share one physical database.
• Invest early in good logging, metrics, and automated tests — these matter just as much in a monolith as in microservices.
• Use feature flags to enable safe, incremental rollouts without needing separate deployable services.
• Keep the build fast — invest in incremental builds and parallel test execution as the codebase grows.
• Revisit the architecture decision periodically (e.g., yearly) using real data, not vibes.

16.2 Common mistakes teams make

• Choosing microservices for résumé‑building or hype reasons rather than actual team/traffic needs.
• Letting a monolith grow without any internal modularity, then blaming “the monolith” instead of the lack of discipline.
• Splitting into microservices along technical lines (e.g., “the database service,” “the API service”) instead of business‑capability lines (e.g., “orders,” “payments”) — this creates chatty, tightly‑coupled services that are worse than the monolith they replaced.
• Underestimating the ongoing operational cost (on‑call burden, tooling, cloud spend) of running many services.
• Migrating to microservices all at once (“big bang”) instead of incrementally, with no way to safely roll back.
• Not measuring anything before deciding — no traffic data, no team‑friction data, just “everyone else is doing it.”

The pattern across public case studies is consistent: match your architecture to your actual, current, measured needs — not to whichever style is fashionable this year.

The pattern across these real examples is consistent: companies with huge, diverse engineering organisations and highly uneven traffic patterns (Netflix, Amazon) benefit from microservices. Companies that prioritise a small, fast‑moving team and predictable, well‑understood traffic (Shopify, Basecamp, Stack Overflow) have publicly and successfully stayed with monoliths — and at least one company (Segment) tried microservices and consciously reversed the decision after measuring the real cost.

This chapter is the practical heart of the tutorial: a concrete, checkable set of signals you can apply to your own team and product right now.

18.1 Signals that favour staying with a monolith

18.2 A step‑by‑step decision process

18.3 A worked example

The most common questions, answered plainly, followed by the short version of everything above.

Summary

A monolith is a single deployable application; microservices split an application into many independently deployable services communicating over a network. Microservices solve real problems — independent scaling, independent deployment, fault isolation, and technology diversity — but only at a cost: significant operational complexity, harder data consistency, higher latency, and a much bigger surface area to secure and monitor.

The right decision is not about which architecture is more modern or more prestigious — it is about matching your architecture to your team size, your domain clarity, your traffic pattern, and your operational maturity. For the large majority of products — especially small teams, evolving domains, and steady traffic — staying with a well‑structured, modular monolith is the correct, evidence‑based, senior‑engineer recommendation, and can be revisited later using real data rather than assumptions.

The architect’s case for the monolith is not that it is always the right choice. It is that it is a first‑class, defensible, evidence‑based choice — and often the more sophisticated one — whenever the specific signals that justify microservices are not yet present. When you can articulate those signals precisely, and honestly measure whether your own product exhibits them, you are already thinking like the senior architect this tutorial set out to help you become.