We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningIntermediate · Microservices Architecture
An architecture where an application is split into small, independent services that communicate over the network. Each service owns its own data and can be deployed separately.
In short
Microservices is an architecture style where a single application is built as a set of small, independent services, each owning one business capability, owning its own data, and communicating over the network through APIs or messages. Because each service is deployed and scaled on its own, teams can ship and update one part of the system without rebuilding or redeploying the whole thing.
In short
Microservices is an architecture style where a single application is built as a set of small, independent services, each owning one business capability, owning its own data, and communicating over the network through APIs or messages. Because each service is deployed and scaled on its own, teams can ship and update one part of the system without rebuilding or redeploying the whole thing.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers Microservices across a run of lessons, not one page. These 4 alone are about 120 minutes of step-by-step reading, 1 of them with code you run in the browser, all with a quiz.
The complete guide to microservices, principles, communication patterns, data ownership, and the real trade-offs nobody talks about.
Path-based routing for microservices request routing, tested on real nginx, Envoy and HAProxy: nginx location order, ALB path rules, Ingress, path vs host.
Long-lived transactions without distributed locking, orchestration vs choreography for microservices.
Aggregate data from multiple microservices into a single response at the API layer.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Microservices Architecturepay once,
yours for life
In a monolith, all the code for every feature lives in one codebase and ships as one deployable unit. Sign-up, checkout, search, and billing all compile together, run in the same process, and share one database. Microservices break that single unit into many smaller services, where each service handles one slice of the business: an Order service, a Payments service, an Inventory service, a Notifications service.
The defining rule is independence. Each service has its own codebase, its own deployment pipeline, and usually its own database. No other service is allowed to reach into that database directly. If the Order service wants stock numbers, it asks the Inventory service over the network instead of running a SQL query against Inventory's tables. This is what people mean by loose coupling, and it is the whole point of the style.
A useful sizing heuristic is that a service should map to one bounded context, a term from domain-driven design. It is not about lines of code. A service is the right size when one small team can own it end to end and explain its job in a sentence.
Services talk to each other in one of two ways. Synchronous calls use HTTP or gRPC, where the caller waits for a response. Asynchronous calls use a message broker like Kafka or RabbitMQ, where a service publishes an event such as OrderPlaced and other services react to it on their own time. Async communication is preferred when you want services to stay decoupled, because the publisher does not need to know who is listening.
Because the network is now in the middle of everything, several supporting pieces become standard. A service registry plus service discovery lets a service find the current address of another. An API gateway sits at the edge and routes external requests to the right internal service, handling auth and rate limiting in one place. A service mesh such as Istio or Linkerd pushes retries, timeouts, mutual TLS, and traffic metrics into a sidecar proxy so application code stays clean.
Resilience patterns are not optional here. A call to another service can fail or hang, so teams add timeouts, retries with exponential backoff and jitter, and circuit breakers that stop hammering a downed dependency. Because one request can fan out across ten services, distributed tracing tools like Jaeger or OpenTelemetry are used to follow a single request across the whole chain.
Microservices earn their cost when you have many teams that keep blocking each other in one big codebase, when different parts of the system have very different scaling needs, or when you want to deploy features dozens of times a day without a full redeploy. Amazon and Netflix moved this way because hundreds of engineers could no longer ship safely from one monolith.
The trade-off is real operational complexity. You are now running a distributed system, which means network failures, partial outages, data that is eventually consistent across services, and far harder debugging. A transaction that spanned one database in a monolith now needs the saga pattern across several services. You also need mature DevOps: containers, Kubernetes, CI/CD per service, centralized logging, and monitoring.
For most early-stage products the honest answer is to start with a well-structured monolith. Martin Fowler's Monolith First advice holds up: split into services only once you understand the domain boundaries and feel the pain of the monolith. Splitting too early gives you a distributed monolith, which has all the network pain and none of the independence.
Picture an online store placing an order. The browser hits the API gateway, which routes to the Order service. The Order service writes the order to its own database, then publishes an OrderPlaced event to Kafka.
The Payments service consumes that event, charges the card, and publishes PaymentCompleted. The Inventory service consumes the order event and decrements stock. The Notifications service consumes PaymentCompleted and emails the receipt. No single service knows the full flow, and each can be deployed, scaled, and even rewritten in a different language without touching the others.
If Payments goes down, the Order service still accepts orders and the event waits in Kafka until Payments recovers. That decoupling, where one failure does not take down the whole checkout, is exactly what the architecture buys you in exchange for the added moving parts.
Netflix
Migrated from a monolith to over 700 microservices on AWS so streaming, recommendations, and billing scale and deploy independently.
Amazon
Famously broke its retail monolith into small two-pizza-team services, each owning its own data and API, in the early 2000s.
Uber
Runs thousands of services for pricing, dispatch, maps, and payments, coordinated through API gateways and a service mesh.
Kubernetes
The de facto platform teams use to deploy, scale, and self-heal containerized microservices in production.
A monolith ships all features as one deployable unit sharing one codebase and usually one database. Microservices split those features into many independent services, each deployed separately with its own database, talking over the network. The monolith is simpler to build and run; microservices give independent scaling and deployment at the cost of operational complexity.
Yes, that is the recommended pattern, called database-per-service. Each service owns its data and no other service reads it directly, which keeps services loosely coupled and independently deployable. Sharing one database recreates tight coupling and is considered an anti-pattern for true microservices.
Two main ways. Synchronously over HTTP or gRPC, where the caller waits for a reply, or asynchronously through a message broker like Kafka or RabbitMQ, where a service publishes an event and others react. Async messaging is preferred when you want services to stay decoupled and resilient to each other's downtime.
Avoid them for small teams, early-stage products, or when domain boundaries are not yet clear. Splitting too early produces a distributed monolith with all the network complexity and none of the independence. Start with a clean monolith and extract services only when you feel real scaling or team-coordination pain.
You cannot use a single database transaction because each service owns its own data. The common solution is the saga pattern, a sequence of local transactions where each service does its part and publishes an event, with compensating actions to undo earlier steps if a later one fails.
Path-Based Routing for Microservices: How a Proxy Picks a Service by URL Path
Path-based routing for microservices request routing, tested on real nginx, Envoy and HAProxy: nginx location order, ALB path rules, Ingress, path vs host.
Saga Pattern
Long-lived transactions without distributed locking, orchestration vs choreography for microservices
API Composition
Aggregate data from multiple microservices into a single response at the API layer
Strangler Fig Pattern
Migrate from monolith to microservices incrementally, replacing pieces one at a time while the old system stays alive
Choreography vs. Orchestration
Two fundamentally different ways to coordinate microservices: decentralized dance vs. centralized conductor
Monolith
A single, unified application where all features share the same codebase and deployment. Simpler to start with but harder to scale individual parts.
Service Discovery
The mechanism by which microservices find and communicate with each other. Services register themselves and others can look them up by name.
API Gateway
A single entry point for all client requests that routes them to the appropriate microservice. Handles auth, rate limiting, and request transformation.
Circuit Breaker
A pattern that stops calling a failing service after repeated failures, preventing cascade failures. Like an electrical circuit breaker that cuts power to prevent fires.
Bulkhead
A pattern that isolates different parts of a system so a failure in one part doesn't sink the whole ship. Named after the compartments in a ship's hull.
Retry
Automatically re-attempting a failed operation, usually with exponential backoff. Essential for handling transient failures in distributed systems.
This page explains the idea. The "Microservices Architecture" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the Microservices Architecture lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about Microservices in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
