Microservices vs Monolith – A Beginner's Guide to Architecture Styles

An online shop lets people browse products, put items in a basket and pay for an order. We can build those features inside one application, or divide them into separate applications that communicate with each other.

Both approaches can serve the same customer. The important difference is how we organise the software, release changes and handle problems. In this lesson, we will compare the two approaches before choosing one for a small team.

A modular monolith is one application with clearly separated parts inside it. The product catalogue and checkout can be separate modules, but the team releases them together. Modules can call each other directly, and related database updates can often be completed together as one transaction—an operation that either succeeds as a whole or is rolled back.

With microservices, features such as the catalogue and checkout run as separate services. A service is an application with a defined job and an interface that other applications can use. The team may release or add copies of one service without releasing the others.

That independence has a cost. Services send messages or requests across a network, and the network can be slow or unavailable. The team must decide what to do when a request times out, how to follow an operation across services, and how to keep related information consistent.

Either approach can run on several servers. Adding servers does not automatically require microservices; a monolith can also have multiple running copies.

The shop is receiving requests to view its catalogue. Compare one copy of a modular application with three copies of a separate catalogue service. A running copy is also called a replica.

This example assumes that the single application can handle 800 catalogue requests per second, while each catalogue-service copy can handle 400. The three copies therefore have a combined capacity of 1,200. These are different resource budgets, chosen to help explain the calculation—not evidence that microservices are inherently faster.

Switch the deployment model and increase incoming traffic. Notice when work begins to arrive faster than the selected setup can process it. Then consider whether extra copies of the monolith could solve the same capacity problem.

Suppose a customer clicks “Pay”, but the shop does not receive a reply from the payment provider in time. The payment might have failed, or it might have succeeded while the reply was lost. Charging again immediately could make the customer pay twice.

Give each payment attempt a unique identifier, often called an idempotency key. When the payment API supports this key, repeated requests for the same attempt can be recognised instead of creating another charge. Keep the order in an explicit “awaiting confirmation” state until the outcome is known.

If a monolith’s process stops, several features can become unavailable together. Separate services can limit the affected area, but only if their callers stop waiting after a sensible time and avoid endlessly repeating failed requests. A service boundary alone does not guarantee isolation.

A monolith can use Strategy and Facade without becoming distributed. Independent service owners may need Saga or Outbox because their commit boundaries differ.

Choose an architecture by asking who maintains the system, which features need to change independently, and what happens when a part fails. A small team can often begin with a modular monolith and keep its internal boundaries clear.

Separate a service when there is a concrete need, such as different release schedules or an independently busy feature. Weigh that benefit against the extra communication and operational work.