Core Concepts

What are Microservices? (vs a Monolith)

A monolith is one application, deployed as one unit, containing all the features. Microservices split the system into small services, each owning one business capability and its data, deployed independently and talking over the network. Neither is better in general; they trade simplicity against independent scaling and team autonomy.

In simple words

A monolith is one big restaurant kitchen where everyone cooks everything together. Microservices are a food court: separate stalls (pizza, drinks, desserts) that open, close and hire staff independently, but now they have to coordinate to serve one combo meal.

A monolith is one deployable with one database; microservices each own their code and data and talk over the network.

Why Microservices Exist

As a product and its team grow, one codebase becomes a coordination problem: every deploy ships everything, one bug can take down all features, and teams block each other. Splitting by business capability lets teams own, deploy and scale their part independently.

How It Works

Monolith                               Microservices
+-------------------------------+      client -> API gateway
|  users | orders | payments    |               /     |      \
|  catalog | search | email     |          users   orders   payments
|         one database          |           [db]    [db]      [db]
+-------------------------------+        (each owns its data; talk via
  one deploy, in-process calls            REST/gRPC calls and events)

Comparison

	Monolith	Microservices
Deploy	all at once	each service independently
Scaling	scale the whole app	scale only the busy service
Calls	in-process function calls (fast, reliable)	network calls (latency, partial failure)
Data	one DB, easy joins and transactions	DB per service; cross-service consistency via sagas/events
Operations	simple	needs service discovery, tracing, CI/CD per service
Best for	small teams, early products	many teams, clear domain boundaries, uneven load

Key Pointers

Start with a well-structured (modular) monolith; extract services when a real pain appears.
Split by business capability, and give each service its own data; a shared database recreates the coupling.
Every network call can fail or be slow: timeouts, retries, circuit breakers and idempotency become mandatory.
Distributed transactions are replaced by sagas and eventual consistency.

Follow-up Questions

How do microservices keep data consistent without a shared transaction?: Each service commits locally and publishes an event (often via the transactional outbox pattern); other services react. Multi-step business processes use sagas with compensating actions when a step fails.
What is a "distributed monolith"?: Services that must be deployed together or call each other synchronously in long chains, often sharing a database: all the costs of microservices with none of the independence.
How do services find each other?: Service discovery: a registry (Consul, Kubernetes Services/DNS) maps service names to healthy instances, often with client-side or sidecar load balancing.