Microservices

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.