Microservices Architecture

A microservices architecture splits an application into small, independent services, each owning one business capability and each deployable on its own. Orders is one service, payments is another, search is a third. They talk over the network through APIs or messages instead of calling each other as in-process function calls. The opposite end of the spectrum is the monolithic architecture, where every feature lives in one codebase and ships as one unit. In between sits service-oriented architecture (SOA), the older enterprise approach that shares an integration bus and often a database. Microservices push that idea further by making each service genuinely independent, down to its own datastore.

The split is not really about size. It is about ownership and blast radius. When the catalog team can deploy ten times a day without coordinating with the payments team, and a memory leak in recommendations cannot crash checkout, you have the property microservices exist to give you. The cost is that you have traded simple function calls for network calls, one database for many, and one log file for distributed tracing across a dozen processes.

This is why the category covers both halves. The classic design patterns (singleton, factory, observer, strategy, adapter, proxy, decorator, facade, command, chain of responsibility, mediator, repository, aggregate) keep the code inside each service clean and replaceable. The distributed patterns keep the system between services honest. You need both. A microservice with a tangled internal design is just a small monolith you now have to call over HTTP.

The hardest part of microservices is not the code, it is drawing the lines. Domain-driven design (DDD) gives you the vocabulary for this, and the central idea is the bounded context: a clear edge inside which a word like "order" or "customer" means exactly one thing. Each bounded context usually maps to one service. Get the boundaries wrong and you build a distributed monolith where every change still touches five services at once, which is worse than the monolith you started with.

Data ownership follows directly from the boundaries. Database per service means each service owns its tables and no other service reaches in. This is what lets teams change their schema freely, but it forces you to give up cross-service joins and distributed transactions. The shared database pattern is the shortcut teams take to avoid that pain, and the lessons are honest about why it usually becomes the bottleneck that re-couples everything. The aggregate pattern and repository pattern from DDD help you keep each service's own data consistent without leaking that responsibility outward.

Once you have many services, infrastructure becomes a topic in its own right. Service discovery answers "where is the inventory service right now" when instances come and go constantly. A service mesh moves retries, timeouts, encryption, and traffic routing out of your application code and into a sidecar proxy that runs next to every service. The category covers service mesh concepts and a concrete implementation, plus the container patterns that make it work: sidecar, ambassador, and adapter containers.

The first real decision is when to split at all. A monolith is the correct choice for a small team and an unproven product. The patterns that matter for moving off it are the strangler fig pattern, where you grow the new system around the old one and retire the old code path by path instead of in one risky rewrite, and the anti-corruption layer, which translates between the legacy model and your clean new one so the old design does not infect the new services.

The second decision is how services coordinate a multi-step workflow, such as placing an order that touches inventory, payment, and shipping. Choreography lets each service react to events on its own, which keeps services loosely coupled but scatters the business logic across the system so no single place describes the whole flow. Orchestration puts one coordinator in charge of the sequence, which is easier to read and debug but creates a central piece that every workflow depends on. The choreography versus orchestration lesson lays out exactly when each one earns its keep.

The third set of trade-offs is about failure, because in a distributed system failure is the default state, not the exception. Retry logic recovers from transient errors, but naive retries cause retry storms that knock over the service you were trying to reach. Exponential backoff spaces those retries out, and jitter randomizes the timing so clients do not all retry in the same instant. The circuit breaker pattern stops calling a service that is clearly down so you fail fast instead of piling up. The bulkhead pattern isolates resource pools so one drowning dependency cannot consume every thread. Back pressure pushes load back upstream when a consumer cannot keep up, and graceful degradation keeps the core experience working when a non-essential service is gone, like serving a product page without its recommendation strip.

Netflix is the textbook case. They moved from a monolithic DVD-rental system to hundreds of microservices on AWS after a single database failure took the whole service down for days. The resilience patterns in this category (circuit breakers, bulkheads, graceful degradation) came directly from that environment, where any one service can fail at any time and the product still has to play video. Their tooling popularized failing fast and shedding non-essential features under stress rather than letting the whole page go dark.

Amazon's two-pizza teams are the organizational mirror of database per service: small teams that own a service end to end, including its data and its on-call. Their internal rule that all teams must talk to each other only through service interfaces, with no shared databases and no back doors, is the discipline that made the architecture (and later AWS) possible. Uber rebuilt its early monolith into a domain-oriented microservices platform as it expanded across cities, leaning heavily on service discovery and a service mesh to manage thousands of services.

The lesson from all three is that microservices are an organizational tool as much as a technical one. The architecture lets a large engineering group ship in parallel without constant coordination. If you are a team of five, you get most of the cost and little of the benefit, which is why every serious treatment of the topic, including this one, tells you to earn your way into microservices rather than starting there.