Microservices Architecture
Monolith vs Microservices — Trade-offs and When to Split
Evaluating database isolation boundaries, operational complexity, and domain structures.
Introduction
A Monolithic architecture packages all functional domains of an application into a single deployable artifact sharing a unified database. A Microservices architecture splits these domains into small, autonomous, decoupled services that run as independent processes and communicate over lightweight networks.
Why It Matters
Microservices solve organizational scalability bottlenecks and enable high-speed independent deployments. However, they are not a default standard. Splitting too early or without operational readiness introduces severe overhead: network latency, distributed transaction limits, data consistency challenges, and deployment complexity. Understanding how to evaluate these trade-offs is critical to building robust architectures.
Real-World Analogy
Think of a Monolith like a multi-purpose Swiss Army knife. It houses a knife, scissors, and bottle opener in a single handle. It is simple to carry and use. But if the scissors break, you must repair or replace the entire tool. Think of Microservices like a professional toolkit with a separate screwdriver, knife, and scissors. Each tool can be replaced or sharpened independently. However, carrying and organizing the toolkit requires a specialized toolbox (Kubernetes/Infrastructure) and introduces more overhead.
Detailed Mechanics
1. Defining Bounded Contexts (DDD)
To split a monolith successfully, developers rely on Domain-Driven Design (DDD). A Bounded Context defines the logical boundary of a specific domain model (e.g. Order Processing, Shipping, Billing). Each microservice should ideally match exactly one Bounded Context to minimize functional overlaps.
2. The Database-Per-Service Pattern
In a true microservices setup, each service must exclusively own its database schema. Services are strictly prohibited from accessing another service's database directly. If Service A needs data owned by Service B, it must fetch it through Service B's public APIs (REST/gRPC/Messaging). This isolation ensures schemas can be updated independently without breaking downstream services.
Comparison Table
| Criterion | Monolithic Architecture | Microservices Architecture |
|---|---|---|
| Deployment | Single deployment unit (All or nothing) | Independent deployments per service |
| Transactions | ACID (Local database level, easy rollbacks) | Eventual consistency (Saga patterns, complex) |
| Operational Overhead | Low (Simple build pipelines, unified logs) | High (Service discovery, distributed tracing needed) |
| Network Overhead | Minimal (In-memory calls between classes) | High (Frequent HTTP/gRPC network hops) |
Quick Quiz
Q1: Why is sharing a single central database among multiple microservices considered an anti-pattern?
A) It increases hosting costs.
B) It causes database connection limits to exceed immediately.
C) It bypasses API contracts, creating tight coupling at the database level and preventing services from updating their schemas independently.
D) Java does not compile if databases are shared.
Answer: C — Database-per-service is mandatory to enforce API-only communication boundaries, preserving domain decoupling.
Q2: When is a monolithic architecture typically more appropriate than microservices?
A) When the domain is complex and team size is very large.
B) In early-stage startups or MVPs where domain boundaries are still shifting and operational complexity should be minimized.
C) Only when using PHP instead of Java.
D) When you want to run completely serverless processes.
Answer: B — Monoliths reduce operational complexity, allowing fast iterations when business boundaries are not yet fixed.
Scenario-Based Challenge
Production Scenario:
Your company splits a monolithic web application into 15 microservices. However, you find that in order to deploy a single update to the Order Service, developers must synchronize and deploy updates to the Customer Service and Inventory Service at the exact same time. What architecture anti-pattern have you built, and how do you resolve it?
View SolutionYou have built a **Distributed Monolith**. This happens when services are split physically but remain tightly coupled via synchronous dependencies or shared data structures, inheriting all the network latency of microservices without the benefit of independent deployments. To resolve this:
- Review service boundaries: merge highly coupled services back together if their business boundaries cannot be cleanly separated.
- Decouple communications: replace synchronous REST dependency calls with asynchronous event messaging (e.g. using Kafka topics) to allow services to operate independently.
Interview Questions
1. Conceptual: What is Conway's Law and how does it relate to microservices?
Conway's Law states that organizations design systems that copy their own internal communication structures. If an organization has independent, small, cross-functional teams, they naturally build decoupled microservices. If they have one large monolithic department, they tend to build monolithic applications.
2. Concept: How do you handle reporting or analytics across independent microservice databases?
Do not run SQL joins across databases. Instead, implement a **Data Lake** or **Data Warehouse** system. Each microservice publishes events when database values change (using Change Data Capture - CDC). An ELT pipeline streams these updates into a central data store (e.g. Snowflake) where reports can be processed without affecting transactional DB pools.
Production Considerations
Never start building a project as microservices from day one unless you have a proven domain model and an experienced operations team. Start with a clean, modular monolith (Logical separation inside code packages) and split the modules into microservices only when scaling requirements dictate it.