Monolith vs Microservices: Making the Right Architecture Choice

Amazon's $1 Billion Lesson

In 2023, Amazon's Prime Video team made headlines by migrating FROM microservices BACK to a monolith. Their distributed video monitoring pipeline had 11 microservices with complex orchestration. Moving to a single process reduced infrastructure costs by 90% and simplified operations dramatically. The lesson: microservices are not always the answer.

The Monolith

A monolith is a single deployable unit containing all your application logic. One codebase, one deployment pipeline, one running process.

Monolith Architecture:

  +------------------------------------------+
  |            Single Deployment              |
  |                                          |
  |  [Users]  [Orders]  [Products]  [Search] |
  |     |        |          |          |     |
  |  [Shared Database - PostgreSQL]          |
  +------------------------------------------+

  Pros:                          Cons:
  - Simple to develop/debug      - Hard to scale parts independently
  - Function calls (fast)        - All teams coordinate deploys
  - ACID transactions (easy)     - One bug can crash everything
  - One codebase to understand   - Tech stack locked in
  - Small team? Perfect.         - Big team? Painful merges.

Microservices

Microservices split the application into small, independently deployable services, each owning its own data and communicating over the network.

Microservices Architecture:

  [API Gateway]
   |   |   |   |
  [Users] [Orders] [Products] [Search]
   |DB|    |DB|     |DB|       |ES|
  (PG)   (PG)    (Mongo)    (Elastic)

  Each service:
  - Own codebase, own database, own deploy pipeline
  - Communicates via HTTP/gRPC/events
  - Scales independently
  - Can use different languages/databases

  Pros:                          Cons:
  - Independent scaling           - Network calls (slow, can fail)
  - Independent deployment        - Distributed transactions (hard!)
  - Tech freedom per service      - Debugging across services (complex)
  - Team autonomy                 - Operational overhead (massive)
  - Blast radius containment      - Need: tracing, service mesh,
                                    discovery, CI/CD per service

The Decision Matrix

Factor                    Monolith        Microservices
------------------------  --------------- ----------------
Team size < 20            YES             Overkill
Team size 20-100          Modular mono    Consider it
Team size 100+            Painful         YES
New product / MVP         YES             Too early
Mature product            Fine if modular YES
Need independent scaling  Difficult       YES
Need independent deploys  Difficult       YES
Operational maturity      Low? Fine.      MUST be high
Transaction complexity    Simple (ACID)   Hard (sagas/2PC)
Debugging                 Simple          Distributed tracing
Latency sensitivity       Fast (in-proc)  Slower (network)

  Key question: "Is the pain of our monolith GREATER
  than the complexity cost of distribution?"
  If not? Stay monolithic.

The Middle Ground: Modular Monolith

Shopify runs one of the largest Rails monoliths in the world. Instead of splitting into microservices, they enforce module boundaries WITHIN the monolith. Each module owns its data, has clear interfaces, and cannot access other modules' internals. This gives most of the organizational benefits of microservices without the distributed systems overhead.

Modular Monolith (Shopify's approach):

  +------------------------------------------+
  |            Single Deployment              |
  |  +--------+  +--------+  +---------+    |
  |  | Users  |  | Orders |  | Products|    |
  |  | Module |  | Module |  | Module  |    |
  |  +---||---+  +---||---+  +----||---+    |
  |      ||          ||           ||         |
  |  Public API   Public API  Public API     |
  |  (no direct DB access across modules!)   |
  |                                          |
  |  [Shared Database - but schema isolated] |
  +------------------------------------------+

  Rules:
  - Modules communicate via public interfaces only
  - No direct SQL across module boundaries
  - Each module can be extracted to a service later
  - You get monolith simplicity + microservice boundaries

Who Uses What

Company       Architecture             Why
-----------   -----------------------  ----------------------------
Shopify       Modular monolith (Ruby)  Team boundaries without dist
StackOverflow Monolith (.NET)          10M users on 9 web servers
Netflix       ~1000 microservices      100M+ users, 2000+ engineers
Uber          ~4000 microservices      Global, multi-product
Bascamp/HEY   Monolith (Rails)         Small team, simple product
Amazon        Microservices + monos    Mix - team decides per service

Interview Tip

When an interviewer asks about architecture choice, say: 'I would start with a modular monolith. Clear module boundaries, enforced interfaces, but single deployment. This lets a small team move fast without distributed systems overhead. If specific modules need independent scaling or deployment - say the search service needs Elasticsearch while everything else uses PostgreSQL - I would extract those modules into services using the strangler fig pattern. I would never split everything at once.'

Key Takeaway

Monoliths are simpler and faster to build. Microservices enable independent scaling and deployment. Start with a monolith, split into services only when organizational or scaling pain demands it. Premature microservices are one of the most expensive architectural mistakes.