Motivation

The microservices vs monolith debate is the single most overcooked topic in system design. The truth is unglamorous: the right architecture is the one that lets your team ship safely at the rate the business demands. For a 5-engineer startup that means a monolith. For Amazon (1000s of services, deploy every 11.6 seconds) it means microservices. For most companies, it means somewhere in between.

Why do interviewers care so much? Because picking the wrong point on the continuum is enormously expensive in two directions:

• Microservices too early: a 5-engineer team adopting Kubernetes, service mesh, distributed tracing, and 8 services to ship a CRUD app spends 80% of their time on infra instead of product. The startup graveyard is full of these.
• Monolith too long: a 200-engineer team on one Rails monorepo where every deploy is a 4-hour merge train, every change risks breaking unrelated features, and onboarding a new team takes 6 months. The brownfield consulting market is full of these.

A senior engineer can name both failure modes, place the current system on the continuum, and propose a credible move along it. That is the bar this lesson teaches.

Deep Dive

The architecture continuum

Microservices vs monolith is a false binary. The real spectrum has at least four points:

[ Monolith ] -> [ Modular Monolith ] -> [ Services ] -> [ Microservices ]
   single        single deploy,           ~5-30           50+ services,
   deploy        strict module            independent     independent teams,
   one DB        boundaries,              services,       independent data,
                 maybe one DB             shared infra    polyglot OK

Monolith. One codebase, one deploy artifact, one database. Functions call functions. No network in the critical path inside the app.

Modular monolith. Same single deploy and (often) single DB, but the codebase is split into hard module boundaries that talk only through explicit APIs. You can cross-module call, but you cannot reach into another module's tables. Shopify, GitHub, and Stack Overflow famously run this way.

Services (a few). A handful (5-30) of independently deployable services, often built around a shared library, a shared schema, or a single team owning multiple services. Less ceremony than full microservices.

Microservices. Many small services (often 1 service per team or per bounded context), independently deployed, independently scaled, with their own data store. Inter-service communication is over the network. Polyglot is allowed.

The tax you pay for distribution

The cheap mental model: every function call you turn into a network call gets 1000x slower and 100x more failure-prone.

This 'distribution tax' is the single most under-estimated cost. A function call inside a Python process that took 50 nanoseconds becomes a 1 ms HTTP call, plus a possible timeout, plus a retry, plus a circuit breaker, plus a metric, plus a span in your tracing system. Multiply by the number of edges in your service graph and you get an idea of the operational surface area.

Conway's Law: org chart drives architecture

Melvin Conway in 1968: 'Organizations design systems that mirror their communication structure.'

The modern reading: if you have 4 teams, you will end up with 4 services (or 4 modules in a monolith), no matter what diagram you draw on day one. Trying to fight this is futile; the right move is to design teams around the boundaries you want.

The pragmatic corollary, called Inverse Conway Maneuver: change the org chart to get the architecture you want.

+-------------------+         +-------------------+
| 4 teams,          |  ===>   | 4 services with   |
| 1 monolith        |  6 mo   | 1 owner each      |
+-------------------+         +-------------------+

If you have 5 engineers total, you do not have 5 teams. You have 1 team. Therefore you should have 1 deploy unit. Therefore you should have a monolith.

Data ownership: the hardest part

Microservices means each service owns its data. No shared database. No reaching across to another service's tables. If service A needs data from service B, it calls B's API.

This sounds clean and is brutal in practice:

• Joins disappear. A query that was SELECT users.*, orders.* FROM users JOIN orders becomes 'call user-service, then call order-service for each user, then merge in app code' (the classic N+1 problem).
• Transactions disappear. You cannot wrap two services in a BEGIN; ... COMMIT;. You need sagas, outbox patterns, or compensating transactions.
• Reporting becomes a separate problem. You build a data warehouse / ETL pipeline because no single DB has all the data anymore.
• Foreign keys are gone. The DB no longer enforces 'this order_id must exist'. You do it in app code. Race conditions appear.

If your team is not ready to own this, microservices will hurt more than help.

What you actually buy with microservices

For all the cost, microservices give real things back:

1. Independent deploys. Team A ships every hour without coordinating with team B. Deployment frequency scales with team count, not codebase size.
2. Independent scaling. The video-encoding service runs on 200 GPU instances. The user-profile service runs on 4 small CPU instances. In a monolith you would scale the whole thing.
3. Fault isolation. A bug in the recommendations service should not take down checkout. (In practice, only with serious circuit-breaker discipline.)
4. Polyglot. Use Python for ML, Go for high-throughput pipes, Rust for the hot loop. In a monolith you mostly pick one language.
5. Team autonomy. A team owns their service end-to-end (build, deploy, on-call). This is the real org win and probably the single biggest reason microservices took off.

Notice how three of the five (independent deploys, independent scaling, team autonomy) are about organizations, not technology. That is the real signal.

What people THINK they buy and don't

Common false promises:

• 'Microservices are easier to test.' They are not. Unit tests are easier. Integration tests are dramatically harder because you have to spin up N services or use brittle contract tests.
• 'Microservices are easier to understand.' Each one is, but the system as a whole is much harder. The graph of who calls whom is the new complexity.
• 'Microservices avoid the big rewrite.' Sometimes. Often the rewrite just becomes a 4-year incremental migration with both systems running.
• 'Microservices give you cloud portability.' No, that is just running in containers. You can do that with a monolith.

Implementation

Patterns and tooling required for microservices to work

If you go microservices, here is the minimum kit you need (and the cost of NOT having each piece):

This is the microservices premium that Martin Fowler talks about: you pay all these costs upfront before you see ANY benefit. If your team is small, you are paying for capacity you do not need.

Migration: the strangler fig

When you do need to move from a monolith to services, the technique that works is Martin Fowler's strangler fig (named after the tropical plant that grows around an existing tree until the original is gone).

Phase 1: only monolith
+----------+      +----------+
|  Client  | ---> | Monolith |
+----------+      +----------+

             Phase 2: introduce a proxy
+----------+      +-------+      +----------+
|  Client  | ---> | Proxy | ---> | Monolith |
+----------+      +-------+      +----------+

             Phase 3: extract one capability
+----------+      +-------+      +----------+
|  Client  | ---> | Proxy | ---> | Monolith |
+----------+      +---+---+      +----------+
                      |
                      v
                 +-----------+
                 | Service A |
                 +-----------+

             Phase N: monolith is empty, can be deleted
+----------+      +-------+      +-----------+
|  Client  | ---> | Proxy | -+-> | Service A |
+----------+      +-------+  |   +-----------+
                             +-> | Service B |
                             |   +-----------+
                             +-> | Service C |

Key rules of a strangler migration:

1. Pick a leaf capability first (notifications, search, billing) where the data dependencies on the rest of the monolith are minimal.
2. Extract via the API, not the database. If service A reads the monolith's tables directly, you are coupled forever. The new service must own its own storage.
3. Use Change Data Capture to seed the new service. Stream from the monolith DB into the new service's DB until you cut over writes.
4. Run dual-write during the transition. Write to both the monolith and the new service, compare reads, fix gaps. This is operationally annoying but catches data drift early.
5. Cut over reads first, then writes. Reads can flip with a feature flag; writes need careful migration of foreign-key data.
6. Delete the old code. The death of a strangler migration is leaving the monolith path 'just in case'. It will live forever.

Service boundaries: Domain-Driven Design

The most common technique for picking service boundaries is bounded contexts from Domain-Driven Design (Eric Evans). Group code that changes together for the same business reason, separate code that changes for different reasons.

A simple heuristic: a good service boundary is one where two adjacent teams almost never need to coordinate on a release. If every change in service A requires a coordinated change in service B, the boundary is wrong: either merge them, or move the misplaced code.

Another heuristic from Sam Newman: a service should be replaceable in 2 weeks by a team that did not write it. If it cannot be, it is too big.

The modular monolith: the underrated middle ground

The most underused architecture in 2026 is the modular monolith. You get most of the benefits of monolith (single deploy, easy debugging, ACID transactions, no network tax) AND you preserve the ability to extract services later.

The rules:

1. One process, one deploy. Same as a monolith.
2. Hard module boundaries. Use language features (Java packages with interface-only exports, Go internal packages, TypeScript module fences, Rust crates) to make cross-module access at compile time impossible except through declared APIs.
3. Shared database is OK, but with a per-module schema. Each module owns a set of tables. Other modules cannot touch them.
4. Module-to-module calls go through the same API surface a future external service would. This is what makes later extraction cheap.

Shopify scaled to billions of dollars of GMV on a Rails modular monolith called the 'Componentized Monolith'. They have written publicly about the discipline required. It works.

When to Use

Decision matrix

If you have two or fewer signals in the right column, do not microservice. Modular monolith.

If you have five or more, you probably should.

If you are in between, services (a few, not many) is the sweet spot.

Anti-patterns

• Distributed monolith: the worst of both worlds. Many services, but they all deploy together because of tight coupling. You pay every microservices cost and get none of the benefits. This is shockingly common.
• Nano-services: services so small (one endpoint each) that the network call dwarfs the work. The function should have stayed a function.
• Shared database: many 'microservices' all writing to the same DB. There is no isolation, no independent deploy, just operational overhead. This is a monolith pretending to be microservices.
• Synchronous chains: A calls B calls C calls D. Latency adds up, failures cascade, and one slow service times out everyone upstream. Async messaging or fewer hops is the cure.

Alternative: serverless

Serverless (FaaS) is its own answer to 'how do I avoid running infrastructure?'. It overlaps with microservices but solves a different problem (no servers, pay per request) at the cost of cold starts and vendor lock-in. Covered in a separate lesson, but worth flagging in interviews when the requirement is bursty workload, not engineering scale.

Case Studies

Amazon: the original microservices story

Amazon famously moved from a monolithic Obidos codebase to thousands of services starting around 2002, driven by Jeff Bezos's mandate that all teams expose their data as services and all services be designed as if external. The numbers people cite are staggering: roughly 50 million deploys per year across the company, a deploy roughly every 11.6 seconds, services owned by '2-pizza teams' (small enough to be fed with two pizzas).

What is rarely told: this took 5 to 7 years of intense platform investment. AWS itself was partly born from this internal platform work. Without that investment, the migration would have been a disaster.

Lesson: microservices at scale work. The platform investment to get there is enormous.

Netflix: cloud-native microservices

Netflix moved from a single Oracle-backed monolith to ~700 microservices on AWS between 2008 and 2012 after a database corruption caused 3 days of outage. They open-sourced large parts of their platform (Hystrix, Eureka, Zuul) in the process.

Netflix is the poster child but their context is unusual: huge engineering org, predictable workload (video streaming), willingness to invest in chaos engineering and platform tooling. Most companies are not Netflix.

Lesson: microservices fit Netflix's combination of scale, predictable load, and engineering investment. Do not assume the same fit applies to your CRUD SaaS.

Shopify: modular monolith

Shopify processes billions of dollars of GMV on a Rails monolith they call the 'Componentized Monolith'. They invested heavily in tooling (custom linters, runtime boundary enforcement, package isolation) to keep modules from leaking into each other. They have a small number of supporting services around the core, but the core is intentionally not microservices.

Lesson: a modular monolith can scale to enormous business volume if you treat the boundaries as seriously as service boundaries.

Segment: rolled back from microservices

In 2018 Segment publicly described moving 140+ destination microservices BACK into a monolith. The microservices version had become unmanageable: 140 services meant 140 sets of dashboards, 140 deploy pipelines, and a shared infrastructure cost that grew faster than the business. Consolidating cut their per-destination cost dramatically and let a small team operate the system.

Lesson: the right architecture changes as you scale up AND down. Senior engineers know when to merge, not just split.

Uber: split, then DOMA

Uber rapidly grew to 2200+ microservices around 2017, then introduced the 'DOMA' (Domain-Oriented Microservice Architecture) framework around 2020 to consolidate adjacent services back into bigger 'domain' groupings. They kept microservices for genuine team-boundary reasons but stopped splitting for the sake of splitting.

Lesson: 'just keep splitting' is not a strategy. Periodic consolidation is part of microservice maturity.

Stack Overflow: famously monolithic

Stack Overflow ran (and largely still runs) one of the most-trafficked sites on the internet on a small set of large servers, a single .NET monolith, and a SQL Server cluster. Their per-request cost is much lower than equivalent microservice deployments. They have publicly defended the choice as deliberate.

Lesson: high traffic does not require microservices. Operational simplicity is a real and underrated business asset.

Quick Review

• Architecture is a continuum, not a binary. Modular monolith is the underrated middle.
• The distribution tax (network latency, partial failures, distributed transactions, observability) is real and large. Pay it only when you need to.
• Conway's Law is the strongest force in the room. Design teams around the architecture you want.
• Microservices buy you team autonomy and independent deploys, mostly. They do not buy you simplicity.
• The strangler fig is the migration pattern that works. Big-bang rewrites do not.
• Senior teams move in BOTH directions on the continuum. Splitting and merging are both legitimate.
• If your team is under 30 engineers, you almost certainly do not need microservices. Build a modular monolith and earn the right to split.