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 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.