10.2.2: Microservices Architectures — Read

From LibreTexts, under CC BY 4.0, as the source states it; its equations are written in TeX, which the PDF shows typeset. This page at LibreTexts.

A microservices architecture takes the idea of modular design even further by decomposing an application into many small, self-contained services, each implementing a single business capability. Unlike a multi-tier monolith (where tiers are logically separated but still part of one application deployment), microservices are independently deployable components [1]. Each microservice typically runs in its own process or container, has its own database or data storage, and communicates with other services via APIs or messaging. This approach offers greater agility and scalability at a granular level: each service can be developed and scaled individually by autonomous teams, enabling faster iterations and deployment independence. For example, an e-commerce system might break out services for user accounts, product catalog, orders, payments, and shipping – each service can be updated or scaled without redeploying the entire application. Microservices architectures are often enabled by containers and orchestration platforms (like Kubernetes), which provide a lightweight way to package and run many services efficiently. They also typically use an API gateway as an entry point, routing client requests to the appropriate backend service, and implementing cross-cutting concerns such as authentication, load balancing, and request routing. The benefits of microservices include improved fault isolation (if one service fails, the others still function) and technology heterogeneity (teams can choose the tech stack per service). However, this style introduces complexity in inter-service communication and requires robust DevOps practices for monitoring and managing distributed components.
Microservices Architecture. Details in caption.

Figure \(\PageIndex{1}\): Typical microservices application architecture. In this reference architecture (based on an AWS example), the application is broken into multiple domain-aligned services rather than traditional horizontal layers. Each microservice (e.g., Account Service, Inventory Service, Shipping Service) has its own datastore – one might use a SQL database, another a NoSQL store or cache, depending on its data needs. Clients interact through an API gateway or load balancer which routes calls to the appropriate service. Services are deployed as isolated units (for instance, in separate containers on Amazon ECS or Kubernetes), enabling each to scale out independently. Notice that common infrastructure components like service discovery, a centralized logging/monitoring system, and an authentication service (not explicitly shown) are often part of a microservices ecosystem to handle the complexity of many moving parts. This architecture increases flexibility and resilience: services can be updated or restarted without impacting others, and if demand spikes for one aspect (say, the catalog service on a sale day), only that service needs to scale out, without over-provisioning the entire application. The trade-off is the added complexity in ensuring all these services communicate reliably and maintaining consistency across distributed transactions (often managed via eventual consistency and messaging patterns). (CC BY 4.0; Felix Amoruwa) Access to a detailed description of Figure \(\PageIndex{1}\)

Microservices Architecture with API Gateway. Details in caption.

Figure \(\PageIndex{1}\): This diagram depicts an application decomposed into independently deployable microservices, each with its own data store, communicating through an API gateway and internal messaging. (CC BY 4.0; Felix Amoruwa) Access to a detailed description of Figure \(\PageIndex{1}\)

This page titled 10.2.2: Microservices Architectures was last modified on Tue, 22 Sep 2026 21:13:47 GMT and is shared under a CC BY 4.0 license and was authored, remixed, and/or curated by Felix Amoruwa.

Contents

Text