Diagramium
🧩 Narrated diagram

Monolith vs microservices

One deployable or many? Walk from a happy monolith to a gateway, per service databases and an event bus, counting the wins and the very real bills along the way.

15 steps3 min readNarrated with a studio voice
Monolith vs microserviceseverything ships togetherone schemacut along business linescheck the token onceowns itowns itowns itorder placedsubscribessubscribeswho is healthyone id, whole journeyA background worker or scheduled job🛠️One deploy for everyoneA web frontend or single-page app🌐The monolithA relational or NoSQL databaseOne shared databaseThe entry point that routes to services🚪API gatewayIdentity, authentication and authorization🔐Auth at the edgeA microservice or backend service⚙️Users serviceA relational or NoSQL databaseUsers databaseA microservice or backend service⚙️Orders serviceA relational or NoSQL databaseOrders databaseA microservice or backend service⚙️Payments serviceA relational or NoSQL databasePayments databaseA queue or event bus for async messaging📨Event busA microservice or backend service⚙️Service registryMetrics, logs and observability📊Distributed tracingA microservice or backend service⚙️Choose by team, not fashion
Monolith vs microservices — the complete diagram. Press Present to watch it build itself.
Step 1 of 15

One deploy for everyone

The pain of a monolith is never the code, it is the calendar. When two hundred engineers ship one artifact, every release becomes a negotiation, one bad line holds back forty teams, and the test suite grows until it takes a full hour.

Step 2 of 15

The monolith

One codebase, one build, one thing to deploy. Almost every company starts here and most should stay far longer than they do. A monolith is not a mistake. Stack Overflow served one of the busiest sites on the web from a single application running on about nine web servers.

Step 3 of 15

One shared database

Everything shares a single database, and that is genuinely lovely. One join answers a question that later needs three network calls, and a transaction either fully happens or fully does not. Whatever else you gain, you will miss this part.

Step 4 of 15

API gateway

So you cut it apart, and the first thing you need is a front door. An API gateway takes every incoming request and routes it to the right service, so the outside world still sees one clean address instead of eleven.

Step 5 of 15

Auth at the edge

Authentication moves to the edge. The gateway validates the token once and passes a trusted identity inward, because the alternative is eleven separate teams each writing their own login code and each getting it slightly, dangerously wrong.

Step 6 of 15

Users service

Now split by business capability rather than by technical layer. Users, orders, payments. The classic wrong cut is a frontend service, a logic service and a database service, because then every single new feature still has to touch all three.

Step 7 of 15

Users database

Here is the rule that makes it real: each service owns its data, and no other service may touch that database. Break this one rule and you have not built microservices, you have built a monolith with network calls in the middle.

Step 8 of 15

Orders service

The prize is independence. Each service can pick its own language, its own release schedule and its own on call rota. The orders team ships at eleven on a Tuesday morning without asking permission from anybody else in the building.

Step 9 of 15

Orders database

But show me this customer's orders with their name now crosses two stores, and there is no join any more. Somebody writes code to stitch the answer together, and that stitching code is exactly where the strange bugs come to live.

Step 10 of 15

Payments service

Failure gets interesting. If payments is slow, orders must not sit and wait forever, so you need timeouts, retries and a circuit breaker that gives up early. A retry storm has taken down more systems than any single crash ever has.

Step 11 of 15

Payments database

Consistency turns from a database guarantee into a design decision. Money moved but the order never updated is now genuinely possible, so every step gets a matching undo step, called a compensating transaction, and the whole chain of them is known as a saga.

Step 12 of 15

Event bus

Much of the traffic stops being requests and becomes events. Orders announces that an order was placed, and payments and email listen. Nobody is called directly, which decouples the teams and also means no single place can tell you what happened.

Step 13 of 15

Service registry

Instances appear and vanish constantly, so nothing can hardcode an address. A registry, or the platform itself, keeps a live list of who is healthy right now, and that list is one more piece of infrastructure you have to run and watch.

Step 14 of 15

Distributed tracing

When one page calls fifteen services, a stack trace is useless. Every request carries an identifier through the whole chain so you can see where four hundred milliseconds actually went. Without tracing, debugging is guesswork billed by the hour.

Step 15 of 15

Choose by team, not fashion

So the honest scoreboard. Microservices buy independent deploys and independent scaling, and charge you in network failures, eventual consistency and a platform team. Below roughly thirty engineers the monolith usually wins. Split when a team is blocked, not when a diagram looks nicer.

Watch it explain itself

Every step above is narrated aloud. Play it, or open it in the editor and make it yours — no account needed.